From daemon@optimus.ietf.org Tue Jan 1 06:38:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11445 for ; Tue, 1 Jan 2002 06:38:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA10545 for sip-archive@odin.ietf.org; Tue, 1 Jan 2002 06:38:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03096; Tue, 1 Jan 2002 06:19:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA03065 for ; Tue, 1 Jan 2002 06:19:54 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11173 for ; Tue, 1 Jan 2002 06:19:49 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g01BJaK09007; Tue, 1 Jan 2002 12:19:36 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g01BJZhO014868; Tue, 1 Jan 2002 13:19:35 +0200 (EET) Message-ID: <3C319BA1.D5D15074@lmf.ericsson.se> Date: Tue, 01 Jan 2002 13:21:05 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: John.Hearty@Level3.com, sip@ietf.org Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C2AC76E.3050208@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>However, if the nodes are separated, and eg MGCP/H.248 is used between >>them, those protocols may define other actions to be taken when media >>failures occur. For example, MGCP allows the media handler to RELEASE >>the call if the media "connection" is lost, so to be able to >>re-establish the session a whole NEW session must be setup. >> >I think that is wrong. I don't think the media handler can release the >call, it can only inform the MGC of errors. That is true for H.248, but when using MGCP the media handler (ie the Media Gateway) IS allowed to release the connection and send DLCX (DeleteConnection) to the call controller (ie the Media Gateway Controller). Also, when using an ATM bearer there are some additional H.248 events indicating bearer failures. Right now I don't remember if any of those events indicate that the connection has actually been released, but I'll look into that... >That would be the "of" event in the MGCP RTP package. As such, the MGC can decide what to do, and in >this case, the spec would say it SHOULD do a re-INVITE. >>And, if the node is a gateway it may not be able to set up a new session in the >>first place, since it's an end-user of either "side" of the gateway >>which set up the session. >> > >This makes no sense whatsoever to me. The UA is in the gateway, and the >RTP session handler is in the gateway. If a gateway detects failure of >RTP, it can certainly send a re-INVITE. Yes, IF all the resources on the PSTN (or whatever gateway we're using) are still reserved, and the session has been "lost" only from a SIP point of view. But, if some of the PSTN resources has also been lost/released, sending a re-INVITE won't help, since the session would have to be re-established also on the PSTN side. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 1 22:40:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20219 for ; Tue, 1 Jan 2002 22:40:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA13044 for sip-archive@odin.ietf.org; Tue, 1 Jan 2002 22:40:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12152; Tue, 1 Jan 2002 22:03:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12120 for ; Tue, 1 Jan 2002 22:03:38 -0500 (EST) Received: from paris.packetizer.org (system@rdu26-244-205.nc.rr.com [66.26.244.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19039 for ; Tue, 1 Jan 2002 22:03:34 -0500 (EST) Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.11.2/8.11.2) with SMTP id g0232FY25452; Tue, 1 Jan 2002 22:02:15 -0500 Message-ID: <005501c19339$e22f3c90$0401a8c0@berlin> From: "Paul E. Jones" To: "Dean Willis" , "Michael Thomas" , "Jonathan Rosenberg" Cc: , , References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> <3C2C938D.2090304@dynamicsoft.com> <15404.57896.511025.223685@thomasm-u1.cisco.com> <200112311707.fBVH7gZ09072@valen.greycouncil.com> Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations Date: Tue, 1 Jan 2002 22:02:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The 576 comes from the IP standard itself... so the smallest should indeed be 576 (see RFC 791). However, I agree that the 1500 bytes is not written in stone. This is a recommended value for some topologies, but it may certainly be higher or lower. Some people are doing PPPoE, which results in a lower MTU in most (or all?) cases. However, I would not necessarily agree with the requirement that a device use TCP if the packets are larger than 1500 octets. I suppose that this a reasonable request to be imposed on the calling device, but what about the called device? What if it needs/wants (for whatever reason) to send a 2000 octet packet when the calling endpoint initiated a call via UDP? If the selection of the transport protocol is left to the calling endpoint, it seems that you've gained little by adding the requirement. I think the only reasonable thing to do is state the problem and leave it for the implementers to handle as they see fit for their particular application. Paul ----- Original Message ----- From: "Dean Willis" To: "Michael Thomas" ; "Jonathan Rosenberg" Cc: ; ; Sent: Monday, December 31, 2001 12:07 PM Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations > > eh, the smallest v4 MTU implementation I've seen was 576 . . . which > was common on old PPP and SLIP implementations. But even so, it can be > challenging to fit into 576 . . . > > -- > Dean > > > > On Friday 28 December 2001 03:20 pm, Michael Thomas wrote: > > Jonathan Rosenberg writes: > > > I would still prefer "MUST" use TCP for packets larger than 1500; > > > your existing devices will be non-compliant (good motivation to > > > fix it) but will still function; I think its fair to say that you > > > still need to be able to receive UDP packets larger than 1500. > > > > Something that needs to be brought up here is that > > 1500 is a fictitious number. Strictly speaking, it's > > more like 256 or so for IP4 and 1280 for IP6. I'm > > not sure we want to go with the IP4 strictness, but > > those are your only guarantees with PMTU. > > > > Mike > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 00:09:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21290 for ; Wed, 2 Jan 2002 00:09:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA15238 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 00:09:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14420; Tue, 1 Jan 2002 23:43:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14389 for ; Tue, 1 Jan 2002 23:43:12 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21082 for ; Tue, 1 Jan 2002 23:43:08 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g024gEVZ005436; Tue, 1 Jan 2002 23:42:15 -0500 (EST) Message-ID: <3C328F8C.30503@dynamicsoft.com> Date: Tue, 01 Jan 2002 23:41:48 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: John.Hearty@Level3.com CC: orton@nortelnetworks.com, brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] Open Issue #139: re-INVITE Glare References: <17052388D394D411803900508BDFFAF601B370D8@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit John.Hearty@Level3.com wrote: > >>I actually posted this to the list over a year back: >> >> I'm afraid this solution does not work as specified. It only works >> if both sides agree they are in a glare situation. Consider the >> following case. A sends a reinvite to B. B receives it, >>and responds >> with a 200. This response takes a while to get to A. Now, B sends a >> re-INVITE to A (as far as B is concerned, the reinvite it received >> has been responded to, thus there is no glare, and it can >>send a new >> re-INVITE). A receives that re-invite. A thinks there is glare, and >> decides its the winner, so it responds. Then, A gets the non-500 >> response from B. Now A is really confused. >> > > This scenario would require packet re-ordering, with B's 200 arriving at > A > after B's re-Invite. These are both going to the same place, and these > days, the likelyhood of packets between the same two places getting > re-ordered is not that high. Granted, there are probabally proxies > between > increasing the likelyhood of the messages getting re-ordered. However, > do > we really want to discard a cleaner solution for a small percentage of > negative scenarios? I have seen arguments in other threads against > solving > problems resulting when the network is totally hosed. Its not reordering, so much as packet loss. All it takes is one or two lost 200 OK's, and the above scenario can happen without the network doing any packet reordering. > > >> You could argue that B shouldn't even send that re-INVITE until the >> ACK is received for the re-INVITE B got first. However, there is >> still a race condition that makes it not work, although its even >> less likely. Heres the case: A sends a re-invite to B that gets >> lost. B sends a re-invite to A. A sees glare, and decides A should >> win, so it responds with a 200 OK. B ACKs, and A gets the >>ACK. Then, that >> lost reinvite arrives at B. B thinks everything is fine, since the >> previous reinvite it sent has been ACKed. So, it sends a 200 >> OK. Now, A is once again confused. It expected B to reject >>that first >> INVITE, since A was declared the winner. >> > > B better not think everything is fine, it just got an Invite with the > same > Cseq it just used. Same CSeq? These are in opposite directions. There is no relationship between the CSeq in each direction. > Again, this scenario requires packet re-ordering > between > the same end points, not a highly likely thing to happen. Packet loss is the problem, as I mentioned above. The proposed > argument of not re-Inviting until after ACK seems to tie back to the > overlapping Invite open issue #113, I am unclear where that left off > other > than it got ugly quickly and it seemed too late to resolve in bis. This > might be another reason to avoid overlapping Invites unless it becomes a > pressing need. I still feel we should avoid timers to resolve glare if > we > can. They are inefficient. I welcome alternatives, but I am pretty sure anything that relies on both sides agreeing that there was glare is not going to work. > > >> >>Now, Brett had proposed a variant: >> >> >>>However I agree with John that something >>>should produce an early winner of the >>>re-INVITE glare. How about allowing the >>>owner of the Call-ID to have the random >>>0 to 2 seconds (by 10ms) and the other >>>gets random between 2.1 and 4 seconds >>>(by 10ms)? Session refreshing induced >>>reinvites should choose higher random >>>backoff intervals assuming that there >>>is time left to accommodate it. >>> >>> >>There are cases where the "owner of the call-id" is also not known. >>Consider the case where A calls B. A crashes. B detects this through >>ICMP on the media channel, and does a re-INVITE to re-establish. A >>backup for A reconstitutes the state, and the call continues. Now, A >>thinks that B owns the Call-ID, and B thinks A owns it. Hmmm. >> > > If A is smart enough to reconstitute state, it ought to be smart enough > to > know if it owned the Call-ID. This could be a condition of the proposal > for > issue #207. Otherwise, we don't have to stick with the "owner of the > Call-ID", there are other things unique to the transactions that could > be > used to derive a definitive early winner. Thats fair enough. This was definitely a minor point in either case; I thought Brett's proposal was reasonable, this issue aside. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 00:20:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21393 for ; Wed, 2 Jan 2002 00:20:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA15348 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 00:20:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14581; Tue, 1 Jan 2002 23:57:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA14552 for ; Tue, 1 Jan 2002 23:57:31 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21211 for ; Tue, 1 Jan 2002 23:57:26 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g024uoVZ005440; Tue, 1 Jan 2002 23:56:51 -0500 (EST) Message-ID: <3C3292F8.9090109@dynamicsoft.com> Date: Tue, 01 Jan 2002 23:56:24 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Dean Willis CC: Michael Thomas , John.Hearty@level3.com, jh@lohi.eng.song.fi, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > eh, the smallest v4 MTU implementation I've seen was 576 . . . which > was common on old PPP and SLIP implementations. But even so, it can be > challenging to fit into 576 . . . I don't think we need to worry about 576. It seems to be OK to take the ethernet MTU and subtract away the various overheads. I seem to recall that we did this for IM and arrived at 1280. Anyway, the interesting question here is handling the case where the request whent UDP and the response should go TCP since its above the path MTU. This can get a bit complicated. One of the complications is that proxies are transactional entities. So, if we take the approach that "when a server has a response that is too large to send, it returns a specific error response telling the client to try tcp", this means that the actual response is effectively dropped on the floor. When the new request arrives over TCP, it will create a new transaction and new processing at the proxy, there is no easy way to correlate them, or for the proxy to know that it needs to now send that previous response. We could try to do that (after all, we can correlate CANCEL to INVITE transactions), but its a larger change. Without the ability to correlate the transactions, I think I can prove that through an N proxy chain, it will reuqire O(N^2) messages to get the final response when this truncation happens. Heres why. Consider the UAC that is connected to proxy P1, which goes to P2, etc., to PN, to the UAS. The original request goes all UDP. The UAS can't send its response over UDP, so its sends the error (say 499 for now). The 499 goes to PN, which now retries over TCP. The response gets to PN, but PN can't forward it to PN-1. So, PN returns 499. PN-1 retries over TCP. This is a new transaction, so PN forwards to the UAS (presumably over TCP this time, otherwise we get an INFINITE ping-pong effect!), which responds. Now, that response goes to PN, to PN-1, which now can't send it to PN-2, so it returns 499. PN-2 retries, and now that request goes all the way to the UAS once more..... and there you have O(N^2). So, I have convinced myself that truncated responses won't work unless there is a way for a proxy to correlate a new transaction with the previous, such that it knows it needs to send the final response it meant to send on the previous, but couldn't. I suppose we could simply include the original transaction ID in the new request, in some header somewhere. The change to bis of using formal transaction IDs in the via branch param makes that feasible. I need to think about if there are any lurking demons with that approach.... Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 01:08:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21763 for ; Wed, 2 Jan 2002 01:08:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA20852 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 01:08:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16039; Wed, 2 Jan 2002 00:57:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16004 for ; Wed, 2 Jan 2002 00:56:59 -0500 (EST) Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21623 for ; Wed, 2 Jan 2002 00:56:56 -0500 (EST) Received: from obsoft.com (localhost.localdomain [127.0.0.1]) by obsoft.com (8.11.6/8.11.6) with ESMTP id g0261OU01555; Tue, 1 Jan 2002 22:01:24 -0800 Message-ID: <3C32A234.FA19EF8E@obsoft.com> Date: Tue, 01 Jan 2002 22:01:24 -0800 From: Bobby Sardana Organization: ObjectSoftware, Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , Michael Thomas , John.Hearty@level3.com, jh@lohi.eng.song.fi, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> <3C3292F8.9090109@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Greetings all: Just curious, why can't the 499 be propagated all the way to the UAC with no intermediary (proxy) storage of responses? So if the request originated as UDP and the UAS cannot handle it, because of size limitations, and requires that a TCP request be made, just reject the request and propagate it (like some other errors) back to the UAC. The UAC can then originate a TCP request. Regards, Bobby Sardana. sardana@obsoft.com Jonathan Rosenberg wrote: > Dean Willis wrote: > > > eh, the smallest v4 MTU implementation I've seen was 576 . . . which > > was common on old PPP and SLIP implementations. But even so, it can be > > challenging to fit into 576 . . . > > I don't think we need to worry about 576. It seems to be OK to take the > ethernet MTU and subtract away the various overheads. I seem to recall > that we did this for IM and arrived at 1280. > > Anyway, the interesting question here is handling the case where the > request whent UDP and the response should go TCP since its above the > path MTU. This can get a bit complicated. > > One of the complications is that proxies are transactional entities. So, > if we take the approach that "when a server has a response that is too > large to send, it returns a specific error response telling the client > to try tcp", this means that the actual response is effectively dropped > on the floor. When the new request arrives over TCP, it will create a > new transaction and new processing at the proxy, there is no easy way to > correlate them, or for the proxy to know that it needs to now send that > previous response. We could try to do that (after all, we can correlate > CANCEL to INVITE transactions), but its a larger change. > > Without the ability to correlate the transactions, I think I can prove > that through an N proxy chain, it will reuqire O(N^2) messages to get > the final response when this truncation happens. Heres why. Consider the > UAC that is connected to proxy P1, which goes to P2, etc., to PN, to the > UAS. The original request goes all UDP. The UAS can't send its response > over UDP, so its sends the error (say 499 for now). The 499 goes to PN, > which now retries over TCP. The response gets to PN, but PN can't > forward it to PN-1. So, PN returns 499. PN-1 retries over TCP. This is a > new transaction, so PN forwards to the UAS (presumably over TCP this > time, otherwise we get an INFINITE ping-pong effect!), which responds. > Now, that response goes to PN, to PN-1, which now can't send it to PN-2, > so it returns 499. PN-2 retries, and now that request goes all the way > to the UAS once more..... and there you have O(N^2). > > So, I have convinced myself that truncated responses won't work unless > there is a way for a proxy to correlate a new transaction with the > previous, such that it knows it needs to send the final response it > meant to send on the previous, but couldn't. > > I suppose we could simply include the original transaction ID in the new > request, in some header somewhere. The change to bis of using formal > transaction IDs in the via branch param makes that feasible. I need to > think about if there are any lurking demons with that approach.... > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 01:17:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21827 for ; Wed, 2 Jan 2002 01:17:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA25368 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 01:17:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16068; Wed, 2 Jan 2002 00:57:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16009 for ; Wed, 2 Jan 2002 00:57:00 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21625 for ; Wed, 2 Jan 2002 00:56:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g025uwVZ005456 for ; Wed, 2 Jan 2002 00:56:58 -0500 (EST) Message-ID: <3C32A10D.3030006@dynamicsoft.com> Date: Wed, 02 Jan 2002 00:56:29 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Open Issue #342: SDP in 488 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit My notes indicate that there had been agreement on the list some time back to allow 488 and 606 to contain SDP, formatted in the same way as an OPTIONS response (which is also not defined at this time), in order to figure out exactly what the capabilities were, which would help explain why the request was rejected. This never made it into bis, and the spec says nothing about this at this time. Do we want to add it in? My proposal is NO. If it hasn't been missed yet, its a sign its not that critical. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 01:19:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21853 for ; Wed, 2 Jan 2002 01:19:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA25397 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 01:19:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18486; Wed, 2 Jan 2002 01:06:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18433 for ; Wed, 2 Jan 2002 01:06:27 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21748 for ; Wed, 2 Jan 2002 01:06:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0266KVZ005478 for ; Wed, 2 Jan 2002 01:06:20 -0500 (EST) Message-ID: <3C32A340.5090008@dynamicsoft.com> Date: Wed, 02 Jan 2002 01:05:52 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Open Issue #370: RTT estimates for 2xx retransmits Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Section 13.3.1.4 talks about how the uas core retransmits the 2xx with intervals that start at t1 and double until t2. These timers should ideally be rtt-tuned, but they are NOT the same measurements as the ones used for sending requests. The reason is that these are almost always through intermediaries, so the rtt estimate is from uas to uac through N proxies. It could be done by including a Timestamp in the 2xx, which is mirrored in the ACK. However, its not clear how to scope that measurement. Note that a similar thing exists for 1xx/PRACK. Should we say anything about this? My proposal is NO, since I think that any such estimation is impossible to be done usefully. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 01:23:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21885 for ; Wed, 2 Jan 2002 01:23:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA25466 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 01:23:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15948; Wed, 2 Jan 2002 00:52:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15917 for ; Wed, 2 Jan 2002 00:52:56 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21603 for ; Wed, 2 Jan 2002 00:52:54 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g025qsVZ005450 for ; Wed, 2 Jan 2002 00:52:54 -0500 (EST) Message-ID: <3C32A019.2050408@dynamicsoft.com> Date: Wed, 02 Jan 2002 00:52:25 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Open Issue #325: Interop with tagless BYE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bis-05 is clear that if you get a BYE outside of a dialog, you reject it. This is self-consistent with BYE handling in bis-05. However, there may be backwards compatibility issues. It is possible that there exist UAs that still send BYE on hangup before the final response to invite is received, and likely that these are sent without To tags. This means that the UAS will get a BYE outside of a dialog. If it ignores this BYE, the call will not be hungup. Do we need to worry about this? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 01:34:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21984 for ; Wed, 2 Jan 2002 01:34:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA25965 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 01:34:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16549; Wed, 2 Jan 2002 01:02:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16516 for ; Wed, 2 Jan 2002 01:02:17 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21733 for ; Wed, 2 Jan 2002 01:02:15 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0262FVZ005469 for ; Wed, 2 Jan 2002 01:02:15 -0500 (EST) Message-ID: <3C32A24A.7080904@dynamicsoft.com> Date: Wed, 02 Jan 2002 01:01:46 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Open Issue #351: non-SIP URL as AOR Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Issue: Do we allow for non-SIP URLs as the address-of-record in a REGISTER? That is, can a REGISTER have a non-SIP URL in the To field? The spec is silent on this, although I think it generally assumes that its OK. I would argue that SIP can only really define proper address bindings for URLs in its own space (i.e., SIP URLs). For example, I do not think it is appropriate for a phone to register that tel:+19739525000 belongs to it. The ownership of this e.164 number is administered outside the scope of SIP systems, and is more the domain of enum to worry about. A proxy would not have access to the proper authorization for such a binding; in enum, these will likely be done statically based on all sorts of complex multi-tiered administration. So, my proposal is that REGISTER be restricted to SIP URls in the To field (Contact can, of course, be anything). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 01:41:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22049 for ; Wed, 2 Jan 2002 01:41:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26072 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 01:41:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16625; Wed, 2 Jan 2002 01:04:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16596 for ; Wed, 2 Jan 2002 01:04:43 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21739 for ; Wed, 2 Jan 2002 01:04:41 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0264fVZ005475 for ; Wed, 2 Jan 2002 01:04:41 -0500 (EST) Message-ID: <3C32A2DC.6050705@dynamicsoft.com> Date: Wed, 02 Jan 2002 01:04:12 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Open Issue #366: sip v. tel URL Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit THe spec is silent on what to do when a user enters just a telephone number at a SIP UA. Does the UA generate a SIP URL using the default domain of the UA, or does it generate a tel URL? Do we even need to say anything about this? We might, since otherwise, a UA that always uses tel won't interoperate with a proxy which doesn't support tel at all. I would probably argue that when a user enters an unqualified name to be called, the UA generates a SIP URL, filling in the domain with its domain of administration. This means that no matter what is entered, it is the domain of the UA which is the one that needs to figure out how to interpret it. This makes it work for things beyond phone numbers. Either way, the spec should talk about this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 02:21:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00415 for ; Wed, 2 Jan 2002 02:21:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA26944 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 02:21:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26284; Wed, 2 Jan 2002 01:57:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26253 for ; Wed, 2 Jan 2002 01:57:40 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22139 for ; Wed, 2 Jan 2002 01:57:38 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g026vRio010189; Wed, 2 Jan 2002 08:57:32 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15410.44887.808389.293629@harjus.eng.song.fi> Date: Wed, 2 Jan 2002 08:57:27 +0200 To: Jonathan Rosenberg Cc: Dean Willis , Michael Thomas , John.Hearty@level3.com, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations In-Reply-To: <3C3292F8.9090109@dynamicsoft.com> References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> <3C3292F8.9090109@dynamicsoft.com> X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > So, I have convinced myself that truncated responses won't work unless > there is a way for a proxy to correlate a new transaction with the > previous, such that it knows it needs to send the final response it > meant to send on the previous, but couldn't. i thought that a stateless proxy doesn't need to correlate anything, but just to route messages to the next hop. what would the problem be if any entity can freely choose to use either udp or tcp to send a message no matter what protocol possible other messages of that transaction were using? -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 02:42:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00575 for ; Wed, 2 Jan 2002 02:42:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA27526 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 02:42:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26677; Wed, 2 Jan 2002 02:00:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26646 for ; Wed, 2 Jan 2002 02:00:51 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23276 for ; Wed, 2 Jan 2002 02:00:48 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0270lio010194; Wed, 2 Jan 2002 09:00:47 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15410.45087.197490.178067@harjus.eng.song.fi> Date: Wed, 2 Jan 2002 09:00:47 +0200 To: Bobby Sardana Cc: Jonathan Rosenberg , Dean Willis , Michael Thomas , John.Hearty@level3.com, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations In-Reply-To: <3C32A234.FA19EF8E@obsoft.com> References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> <3C3292F8.9090109@dynamicsoft.com> <3C32A234.FA19EF8E@obsoft.com> X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bobby Sardana writes: > Just curious, why can't the 499 be propagated all the way to the UAC with > no intermediary (proxy) storage of responses? So if the request originated > as UDP and the UAS cannot handle it, because of size limitations, and > requires that a TCP request be made, just reject the request and propagate > it (like some other errors) back to the UAC. The UAC can then originate a > TCP request. just to ask again, why can't the uas use tcp to send the response even if it got the request using udp? sip should care what the transport protocol is. -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 03:34:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00893 for ; Wed, 2 Jan 2002 03:34:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA29078 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 03:34:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28599; Wed, 2 Jan 2002 03:20:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28569 for ; Wed, 2 Jan 2002 03:20:04 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00814 for ; Wed, 2 Jan 2002 03:20:00 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g028Juio010235; Wed, 2 Jan 2002 10:19:56 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15410.49836.567991.868232@harjus.eng.song.fi> Date: Wed, 2 Jan 2002 10:19:56 +0200 To: Christer Holmberg Cc: Bobby Sardana , Jonathan Rosenberg , Dean Willis , Michael Thomas , John.Hearty@level3.com, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations In-Reply-To: <3C32BED9.9BFF4905@lmf.ericsson.se> References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> <3C3292F8.9090109@dynamicsoft.com> <3C32A234.FA19EF8E@obsoft.com> <15410.45087.197490.178067@harjus.eng.song.fi> <3C32BED9.9BFF4905@lmf.ericsson.se> X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit i agree with christer in that 499 will mess things up very badly. if we can't make sip transport independent, i.e., the *sip* entity should not care how it got a message, then it was a mistake to allow udp in the first place and we should deprecate it. -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:00:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03261 for ; Wed, 2 Jan 2002 08:00:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05435 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:00:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05088; Wed, 2 Jan 2002 07:49:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05057 for ; Wed, 2 Jan 2002 07:49:15 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03136 for ; Wed, 2 Jan 2002 07:49:13 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 032DC4CECF; Wed, 2 Jan 2002 07:48:33 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id HAA17422; Wed, 2 Jan 2002 07:48:30 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id HAA22277; Wed, 2 Jan 2002 07:49:58 -0500 (EST) Date: Wed, 2 Jan 2002 07:49:58 -0500 (EST) Message-Id: <200201021249.HAA22277@fish.research.att.com> To: mat@cisco.com Cc: sip@ietf.org Subject: Re: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-refer-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Mike Thomas wrote, in part: (complete message quoted below) > ... I wonder whether > there's anything *really* serious that could be > abused here. It seems to me that it might be able > defeat screening, but how serious a problem is > that? Opinions differ on how serious something is before it is *really* serious. From a service-provider perspective, being unable to effectively screen calls to a company's CEO will likely result in loss of the contract, and that is *really* serious. > We currently don't have a way to > authenticate RPI either, and though we intend to > get around to fixing that eventually, it doesn't > seem to be a burning need. Agreed that it is not done in the general case, but is done for a large number of useful cases -- with a trusted proxy forwarding requests to the UAS over TLS/IPsec and the UAS accepting only requests from this trusted proxy. Requests that come over other connections can be appropriately flagged by the UAS, or rejected. Sufficient mechanism exists today to do this. > Also: is this something > that really needs to be dealt with by the refer > draft? Could it, say, be dealt with as a > requirement for SIP security? I assume there is sufficient mechanism defined in bis-05 to do SIP security and what is missing is the recommendations on what mechanisms or combination of mechanisms should be used to achieve a secure system (and it is important for the SIP security group to validate this assumption prior to publication of bis). My main concern is that there is not enough mechanism defined in the refer draft to do the job. There is no mechamism defined for the recipient of an INVITE-containing-Referred-By to get any credentials from the party that initiated the REFER. It can't send a 401/407, because that only goes back to the party that initiated the INVITE-containing-Referred-By. So there is a tool missing from the toolkit, and that is the troubling part. Bill Marshall wtm@research.att.com -----original message----- From: Michael Thomas To: William Marshall Cc: sip@ietf.org Subject: Re: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-refer-02.txt William Marshall writes: > I don't believe there has been any conclusion posted about security > aspects of the Referred-By header, which I raised as issues in my > initial review of this draft. > > Without an adequate mechanism to verify the information in the Referred-By > header, and to verify the timeliness of that information, the header is > worse than useless. It should be removed from the draft. > > To repeat the problem, consider three parties, A, B, and C, where > A sends a REFER to B, causing B to send an INVITE to C. Procedures > exist whereby B can authenticate A; procedures also exist whereby > C can authenticate B. > > However, nothing prevents B from including a bogus Referred-By header > in its INVITE request to C. Nothing prevents B from including a > previously-valid-but-expired Referred-By header in its INVITE (i.e. > a form of replay attack). Anything done by C based on information > in the Referred-By header may be incorrect or harmful. Bill, Are there real life threats which would cause C to act in a harmful manner? I mean, I understand the potential for attack, but I guess I wonder whether there's anything *really* serious that could be abused here. It seems to me that it might be able defeat screening, but how serious a problem is that? We currently don't have a way to authenticate RPI either, and though we intend to get around to fixing that eventually, it doesn't seem to be a burning need. Also: is this something that really needs to be dealt with by the refer draft? Could it, say, be dealt with as a requirement for SIP security? Mike _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:01:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03285 for ; Wed, 2 Jan 2002 08:01:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05573 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:01:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04794; Wed, 2 Jan 2002 07:44:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04762 for ; Wed, 2 Jan 2002 07:43:59 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03075 for ; Wed, 2 Jan 2002 07:43:57 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 2 Jan 2002 12:44:22 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Open Issue #259: Proxies Honoring Expires Date: Wed, 2 Jan 2002 12:46:19 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE01122783@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Open Issue #259: Proxies Honoring Expires Thread-Index: AcGOoRCkOci84Pc9Q3i1vHwUuxZv0gE6lekA From: "Jo Hornsby" To: "Jonathan Rosenberg" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA04763 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Proposal: KISS; proxies ignore Expires Agreed. - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:02:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03320 for ; Wed, 2 Jan 2002 08:02:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05608 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:02:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04953; Wed, 2 Jan 2002 07:45:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04854 for ; Wed, 2 Jan 2002 07:44:56 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03089 for ; Wed, 2 Jan 2002 07:44:53 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id HAA17636; Wed, 2 Jan 2002 07:44:55 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g02CisJ1005472; Wed, 2 Jan 2002 07:44:54 -0500 (EST) Message-ID: <3C3300C6.43EFE413@cs.columbia.edu> Date: Wed, 02 Jan 2002 07:44:54 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C32A2DC.6050705@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > THe spec is silent on what to do when a user enters just a telephone > number at a > SIP UA. Does the UA generate a SIP URL using the default domain of the > UA, or > does it generate a tel URL? Do we even need to say anything about this? We > might, since otherwise, a UA that always uses tel won't interoperate with a > proxy which doesn't support tel at all. I don't expect users to actually enter "tel:", so the UA is likely to make the choice based on implementation heuristics. One problem is that the UA may have very limited knowledge as to where it is. If I carry my PDA SIP phone to a new domain (say, a hotel), it knows its home domain (say, cs.columbia.edu), the IP address of its local "outbound" proxy (via DHCP) and that's it. In that case, both possible choices seem reasonable when entering 939-7000: - make it 9397000@cs.columbia.edu, meaning that the number is interpreted in my home domain - make it tel:9397000, meaning the number is interpreted in my visited domain, by the outbound proxy Clearly, the results are going to be rather different if I'm outside Manhattan. For 911 and 411-style phone numbers, the latter is the only viable option until we have a better infrastructure in place. In any event, UAs should probably be prepared to deal with proxies that can't handle tel URLs. Currently, our ability to say unambiguously "URL scheme not supported" is rather weak. 404 doesn't quite fit. This may suggest either a new status code or Warning header value. The best we can probably do is to allow users to choose and have the UA deal with the error case by switching to home resolution. > > I would probably argue that when a user enters an unqualified name to be > called, > the UA generates a SIP URL, filling in the domain with its domain of > administration. This means that no matter what is entered, it is the > domain of > the UA which is the one that needs to figure out how to interpret it. > This makes > it work for things beyond phone numbers. > > Either way, the spec should talk about this. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:04:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03338 for ; Wed, 2 Jan 2002 08:04:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA05645 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:04:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05043; Wed, 2 Jan 2002 07:48:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05012 for ; Wed, 2 Jan 2002 07:48:25 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03118 for ; Wed, 2 Jan 2002 07:48:22 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 2 Jan 2002 12:48:48 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Open Issue #203: transport related params in To/From Date: Wed, 2 Jan 2002 12:50:44 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE011224E5@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Open Issue #203: transport related params in To/From Thread-Index: AcGOpmJrwaZPiGYAQ+iRmCnGSOkJkwE5SDxg From: "Jo Hornsby" To: "Jonathan Rosenberg" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA05013 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > There was one email on this thread supporting the proposal, > and the rest of the thread dealt with additional wording > that might have to be added in support of it. > > I will comment on the extra wording bits below, but > otherwise, I believe there is consensus to accept the > proposal. In that case, port and maddr are disallowed > from the To/From URLs. > > Jo Hornsby wrote: > > I think what I was envisaging was some entity on > > the network ignoring these parameters, and then > > due to some sort of weird transaction keying > > interaction, actually removing them when it > > responded or proxied sommat. > > In this context, having these parameters be "disallowed" > means they MUST NOT be inserted, and MUST be ignored by > any element that receives them there. So, to be honest, > if you do put them in the To field, and the result is > that they get stripped when they come back to you, well, > thats your problem. Bets are off when you send invalid > messages. An implementation might be nice enough to handle > it anyway for you, but its not something the spec would mandate. Fair enough. As long at this is explicitly stated. > > Also, if we take the approach that they should > > just be ignored, then what happens if two requests > > arrive that are otherwise identical apart from the > > port in the To:, say? > > They are identical. Works for me. - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:31:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03565 for ; Wed, 2 Jan 2002 08:31:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA06990 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:31:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06139; Wed, 2 Jan 2002 08:22:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06109 for ; Wed, 2 Jan 2002 08:22:24 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03454 for ; Wed, 2 Jan 2002 08:22:20 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02821K02045; Wed, 2 Jan 2002 09:02:01 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02820hO001719; Wed, 2 Jan 2002 10:02:00 +0200 (EET) Message-ID: <3C32BED9.9BFF4905@lmf.ericsson.se> Date: Wed, 02 Jan 2002 10:03:37 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Bobby Sardana , Jonathan Rosenberg , Dean Willis , Michael Thomas , John.Hearty@level3.com, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> <3C3292F8.9090109@dynamicsoft.com> <3C32A234.FA19EF8E@obsoft.com> <15410.45087.197490.178067@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, First, how would all this work with forking? Assume the following case: UAC_1 sends an INVITE using UDP, which is forked by P_2. UAS_3 receives the INVITE, accepts it and returns a provisional- or 200 response. UAS_4 also receives the INVITE, but wants to use TCP, so it returns 499. Now, when UAC_1 receives the responses, what is it supposed to do? Keep the UDP transaction with UAS_3 alive, and generate a NEW TCP transaction with UAS_4???? Or, is it supposed to terminate (using a tagged BYE) the leg with UAS_3, and initiate a new INVITE using TCP, which again will be forked to both UAS_3 and UAS_4???? And, will there be any tags in the 499 which UAC_1 is supposed to use? Otherwise the new INVITE transaction using TCP may be forked to both UAS_4 and UAS_3, which would mess up UAS_3 if the UDP leg was NOT terminated... Second, if we change the transport protocol in the middle of the transaction (Juha's proposal), how would that affect security, eg if IPSEC is used? Third, I am NOT proposing the remove UDP, but my question is: if we have an application (in our case SIP) which have specific requirements on the transport protocol, and the transport protocol (in our case UDP) can't provide those: why use that transport protocol in the first place???????? Also, how will SCPT affect all this???? My PERSONAL opinion is that what we are doing now (499 response codes, change of transport protocols in the middle of a transaction etc etc etc) is going to mess up, and slow down, things pretty BAD - and it's going to make SIP everything but simple and transport independent (I am NOT saying that we don't have a problem to solve...)... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:33:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03626 for ; Wed, 2 Jan 2002 08:33:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07042 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:33:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06180; Wed, 2 Jan 2002 08:22:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06150 for ; Wed, 2 Jan 2002 08:22:32 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03458 for ; Wed, 2 Jan 2002 08:22:29 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g028BKJ17535; Wed, 2 Jan 2002 09:11:20 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g028BKhO002266; Wed, 2 Jan 2002 10:11:20 +0200 (EET) Message-ID: <3C32C109.2E0659BA@lmf.ericsson.se> Date: Wed, 02 Jan 2002 10:12:57 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John.Hearty@Level3.com CC: jh@lohi.eng.song.fi, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi John, Are you talking about fragmentation on the SIP level, or on the IP/UDP level? I assume you talk about the IP/UDP level, and in that case I don't understand what the SIP application has to do with it. The SIP application shouldn't care if IP packages are fragmented (after all, even if the SIP node itself doesn't do fragmentation, packages may be fragmented by intermediate routers anyway...). If fragments are lost, the UDP checksum will inform the receiver about that. And, the reason we have re-transmits when using UDP is to make sure the receiver will get a "complete" message, in case messages/fragments are lost in the network... Regards, Christer Holmberg Ericsson Finland John.Hearty@Level3.com wrote: > > Hmmm. I'd say all your implementations that support reassembling > fragmented SIP risk problems if there is packet loss. They are making up > for non-compliant devices that are fragmenting the SIP messages (see bis-05 > section 7.5). SIP over unreliable transports should be in one datagram to > maintain the reliability mechanisms built into SIP. If you fragment the > message, the reliability may be lost. > > John Hearty > Level3 > > > -----Original Message----- > > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > > Sent: Friday, December 28, 2001 1:18 AM > > To: sip@ietf.org > > Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations > > > > > > i have nothing against introducing an error response for truncated UDP > > messages, but whatever the new spec will say should not make existing > > implementations that support large udp packets non-compliant. > > > > i have in active use half a dozen different sip phone, > > proxies and media > > gateway controllers and all of them today send and receive > > sip messages > > in udp packets that are larger than 1500 bytes. their network driver > > simply ip fragments and reassembles a packet if it doesn't fit into a > > 1500 byte ethernet frame. almost a year ago i found one ip phone that > > didn't support reception of framented udp packets, but that > > was promptly > > fixed, when i reported the issue. > > > > if the new version of the spec will say (as jonathan > > suggested) "if the > > request is larger than 1500 bytes, you MUST use TCP to send it", then > > such a statement would make all off-the-shelf sip entities that are > > currently in use in my network non-compliant, which would be > > a VERY bad > > idea. > > > > -- juha > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:33:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03639 for ; Wed, 2 Jan 2002 08:33:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07057 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:33:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06030; Wed, 2 Jan 2002 08:21:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05978 for ; Wed, 2 Jan 2002 08:21:44 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03438 for ; Wed, 2 Jan 2002 08:21:41 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02BSfK26975 for ; Wed, 2 Jan 2002 12:28:41 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02BSehO015660 for ; Wed, 2 Jan 2002 13:28:40 +0200 (EET) Message-ID: <3C32EF48.9138AFB0@lmf.ericsson.se> Date: Wed, 02 Jan 2002 13:30:16 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C32A2DC.6050705@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, If we "convert" telephone numbers into SIP URLs, do we need to support TEL URLs in the first place? For URLs which are used for the message "routing" we would allow only SIP URLs (EMAIL/HTTP/whatever URLs would still be allowed in headers where we eg indicate where information/announcements/tones etc etc can be found). Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > THe spec is silent on what to do when a user enters just a telephone > number at a > SIP UA. Does the UA generate a SIP URL using the default domain of the > UA, or > does it generate a tel URL? Do we even need to say anything about this? We > might, since otherwise, a UA that always uses tel won't interoperate with a > proxy which doesn't support tel at all. > > I would probably argue that when a user enters an unqualified name to be > called, > the UA generates a SIP URL, filling in the domain with its domain of > administration. This means that no matter what is entered, it is the > domain of > the UA which is the one that needs to figure out how to interpret it. > This makes > it work for things beyond phone numbers. > > Either way, the spec should talk about this. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:33:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03684 for ; Wed, 2 Jan 2002 08:33:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07092 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:33:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06042; Wed, 2 Jan 2002 08:21:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05980 for ; Wed, 2 Jan 2002 08:21:44 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03439 for ; Wed, 2 Jan 2002 08:21:41 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02CJAK09684 for ; Wed, 2 Jan 2002 13:19:10 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02CJ9hO018400 for ; Wed, 2 Jan 2002 14:19:10 +0200 (EET) Message-ID: <3C32FB1D.6383F289@lmf.ericsson.se> Date: Wed, 02 Jan 2002 14:20:45 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> <3C3292F8.9090109@dynamicsoft.com> <3C32A234.FA19EF8E@obsoft.com> <15410.45087.197490.178067@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, First, how would all this work with forking? Assume the following case: UAC_1 sends an INVITE using UDP, which is forked by P_2. UAS_3 receives the INVITE, accepts it and returns a provisional- or 200 response. UAS_4 also receives the INVITE, but wants to use TCP, so it returns 499. Now, when UAC_1 receives the responses, what is it supposed to do? Keep the UDP transaction with UAS_3 alive, and generate a NEW TCP transaction with UAS_4???? Or, is it supposed to terminate (using a tagged BYE) the leg with UAS_3, and initiate a new INVITE using TCP, which again will be forked to both UAS_3 and UAS_4???? And, will there be any tags in the 499 which UAC_1 is supposed to use? Otherwise the new INVITE transaction using TCP may be forked to both UAS_4 and UAS_3, which would mess up UAS_3 if the UDP leg was NOT terminated... Second, if we change the transport protocol in the middle of the transaction (Juha's proposal), how would that affect security, eg if IPSEC is used? Third, I am NOT proposing the remove UDP, but my question is: if we have an application (in our case SIP) which have specific requirements on the transport protocol, and the transport protocol (in our case UDP) can't provide those: why use that transport protocol in the first place???????? Also, how will SCPT affect all this???? My PERSONAL opinion is that what we are doing now (499 response codes, change of transport protocols in the middle of a transaction etc etc etc) is going to mess up, and slow down, things pretty BAD - and it's going to make SIP everything but simple and transport independent (I am NOT saying that we don't have a problem to solve...)... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:36:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03767 for ; Wed, 2 Jan 2002 08:36:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07314 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:36:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06320; Wed, 2 Jan 2002 08:24:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06289 for ; Wed, 2 Jan 2002 08:24:53 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03498 for ; Wed, 2 Jan 2002 08:24:50 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g025tIK11043; Wed, 2 Jan 2002 06:55:18 +0100 (MET) Received: from lmf.ericsson.se (E0000864A0D27.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g025tHhO025329; Wed, 2 Jan 2002 07:55:17 +0200 (EET) Message-ID: <3C32A128.471DB380@lmf.ericsson.se> Date: Wed, 02 Jan 2002 07:56:56 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: Jonathan Rosenberg , John.Hearty@Level3.com Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C2AC76E.3050208@dynamicsoft.com> <3C319BA1.D5D15074@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Some more issues on this. First, if the UAS has NOT (maybe because of media direction reasons etc) noticed the media failure the re-INVITE will be treated like a any re-INVITE, and if the SDP hasn't changed it will simply trigger a response... Second, IF the UAS has noticed the media failure it would also send a re-INVITE (possible with new SDP parameters, if new resources must be reserved) and we may get a re-INVITE race condition (see Open Issue #139). Third, if a intermediate SIP node (eg a SIP proxy controlling a media server) detects the failure, it won't be able to do anything. Should it then simply wait for the re-INVITE? Fourth, I think that in many (most?) cases the failure will be in the network, on a IP-or-lower level, and not in the SIP end nodes, in which cases a re-INVITE won't help anyway... Just my thoughts... Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > > Hi, > > >>However, if the nodes are separated, and eg MGCP/H.248 is used between > >>them, those protocols may define other actions to be taken when media > >>failures occur. For example, MGCP allows the media handler to RELEASE > >>the call if the media "connection" is lost, so to be able to > >>re-establish the session a whole NEW session must be setup. > >> > >I think that is wrong. I don't think the media handler can release the > >call, it can only inform the MGC of errors. > > That is true for H.248, but when using MGCP the media handler (ie the > Media Gateway) IS allowed to release the connection and send DLCX > (DeleteConnection) to the call controller (ie the Media Gateway > Controller). > > Also, when using an ATM bearer there are some additional H.248 events > indicating bearer failures. Right now I don't remember if any of those > events indicate that the connection has actually been released, but I'll > look into that... > > >That would be the "of" event in the MGCP RTP package. As such, the MGC can decide what to do, and in > >this case, the spec would say it SHOULD do a re-INVITE. > >>And, if the node is a gateway it may not be able to set up a new session in the > >>first place, since it's an end-user of either "side" of the gateway > >>which set up the session. > >> > > > >This makes no sense whatsoever to me. The UA is in the gateway, and the > >RTP session handler is in the gateway. If a gateway detects failure of > >RTP, it can certainly send a re-INVITE. > > Yes, IF all the resources on the PSTN (or whatever gateway we're using) > are still reserved, and the session has been "lost" only from a SIP > point of view. But, if some of the PSTN resources has also been > lost/released, sending a re-INVITE won't help, since the session would > have to be re-established also on the PSTN side. > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:36:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03781 for ; Wed, 2 Jan 2002 08:36:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07328 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:36:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06094; Wed, 2 Jan 2002 08:22:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06064 for ; Wed, 2 Jan 2002 08:22:07 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03448 for ; Wed, 2 Jan 2002 08:22:04 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g027I7K22481; Wed, 2 Jan 2002 08:18:07 +0100 (MET) Received: from lmf.ericsson.se (E0000864A0D27.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g027I7hO029351; Wed, 2 Jan 2002 09:18:07 +0200 (EET) Message-ID: <3C32B490.E139FC64@lmf.ericsson.se> Date: Wed, 02 Jan 2002 09:19:44 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C32A2DC.6050705@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, If we "convert" telephone numbers into SIP URLs, do we need to support TEL URLs in the first place? For URLs which are used for the message "routing" we would allow only SIP URLs (EMAIL/HTTP/whatever URLs would still be allowed in headers where we eg indicate where information/announcements/tones etc etc can be found). Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > THe spec is silent on what to do when a user enters just a telephone > number at a > SIP UA. Does the UA generate a SIP URL using the default domain of the > UA, or > does it generate a tel URL? Do we even need to say anything about this? We > might, since otherwise, a UA that always uses tel won't interoperate with a > proxy which doesn't support tel at all. > > I would probably argue that when a user enters an unqualified name to be > called, > the UA generates a SIP URL, filling in the domain with its domain of > administration. This means that no matter what is entered, it is the > domain of > the UA which is the one that needs to figure out how to interpret it. > This makes > it work for things beyond phone numbers. > > Either way, the spec should talk about this. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:36:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03797 for ; Wed, 2 Jan 2002 08:36:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07342 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:36:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05947; Wed, 2 Jan 2002 08:19:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05915 for ; Wed, 2 Jan 2002 08:19:24 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03418 for ; Wed, 2 Jan 2002 08:19:22 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 45F881E01F; Wed, 2 Jan 2002 08:19:24 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA17728; Wed, 2 Jan 2002 08:19:21 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA03415; Wed, 2 Jan 2002 08:20:57 -0500 (EST) Date: Wed, 2 Jan 2002 08:20:57 -0500 (EST) Message-Id: <200201021320.IAA03415@fish.research.att.com> To: rsparks@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-refer-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Robert Sparks wrote in part: > I _don't_ believe we need to block REFER on the output of the > security team work, as long as we leave the plumbing Referred-By > gives us. Agreed that this is the key point. REFER depends on bis. Bis depends on the output of the security team work. So effectively, it already is. If the security team determines that additional mechanisms are needed in SIP, then definitions would be added to the bis draft. If additional mechanisms are needed to support REFER, they need a place. What I'm really asking is that any additional mechanisms needed to support security of REFER be added to the refer draft. In terms of procedures, I think this means the last call period for draft-ietf-sip-refer-02 needs to be extended until the security team has finished their work and determined whether sufficient mechanisms exists or whether additional mechanisms need to be defined. Bill Marshall wtm@research.att.com -----original message----- From: Robert Sparks To: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip -refer-02.txt Date: Fri, 28 Dec 2001 14:15:53 -0500 > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, December 28, 2001 12:18 PM > To: sip@ietf.org > Subject: RE: [Sip] SIP WG - 5 - Last Call Open Discussion - > draft-ietf-sip-refer-02.txt > > > Robert Sparks wrote, in part: > > ... The current proposal > > is to leave REFER as is, and specify usage of the > parameters available > > on the Referred-By header to get exactly the protection you > describe for > > the transfer application. > > I've looked through draft-ietf-sip-cc-transfer-05 again, and don't see > it. What I see in the transfer draft is more of a "transferree/ > transfer-target just do exactly as they are told, don't question > anything, and it will work". > Well, you don't see it because its not there yet. This was what was being discussed at the SIPPING meeting - the transfer draft is going to have to discuss securing Transfer and add some more example cases before we can push it up. > The transferee and transfer target need some way to protect themselves > from malicious REFER requests, and from malicious INVITES that contain > Referred-By values. I'm afraid that if the restricted usage is > documented in the transfer draft, then deployed implementations > will accept ONLY the combinations of parameters given in the transfer > draft, effectively cutting off new and different services. I feel > a generic method is needed in the refer draft that achieves > some level > of protection against bogus and replayed requests, which can then > be used (at the recipient's option) in all the flows appearing in > call-control drafts. Protection from malicious REFER should be achieved through the same mechanism that protection from malicious INVITE/reINVITEs is achieved, and the REFER draft is not the place to specify that. Protection from malicious Referred-By header values is the only thing that could be discussed in the REFER draft, and please remember that at one point, the draft _did_ provide one concrete mechanism (using a PGP-based signature scheme). The group directed me to pull that out, leaving the syntactic-components that would allow a generalized approach to be used once it was specified. What I think your question boils down to is "Is it ok to advance REFER before that generalized approach has been specified?". Sufficient plumbing is in place to use that approach whenever it becomes available (and other future approaches that may come around). > > If the usage restrictions were to be included in the transfer draft, > they would be something like: accept a REFER only within an active > dialog; accept an INVITE with a Replaces header only if the Call-ID > in the Replaces header matches an active dialog and the Referred-by > header matches either From or To of the same dialog, etc. But > these kind of restrictions kill the blind transfer case (6.1). > But the transfer-target needs to know that the INVITE in step 9 is > not a replay of an ancient REFER (step 7). If all the flows in > the transfer draft were to be allowed, there would be no restrictions > at all. Hardly a workable end state. That's not necessarily the full scope of the kinds of mechanisms the transfer draft could discuss. The full range of candidates for security mechanisms could be brought to bear, from policy based on presence of secured transport to pushing around S/MIME bodies based on public keys. And this gets to the variant of the question above "Is it ok to run ahead of the security subteam and specify some form of security usage in the Transfer draft, or do we block Transfer on their output?" I think those two questions are framed correctly - in particular, I _don't_ believe we need to block REFER on the output of the security team work, as long as we leave the plumbing Referred-By gives us. > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: Robert Sparks > To: "'William Marshall'" , sip@ietf.org > Subject: RE: [Sip] SIP WG - 5 - Last Call Open Discussion - > draft-ietf-sip > -refer-02.txt > Date: Thu, 27 Dec 2001 16:05:04 -0500 > > > > -----Original Message----- > > From: William Marshall [mailto:wtm@research.att.com] > > Sent: Thursday, December 27, 2001 10:50 AM > > To: sip@ietf.org > > Subject: Re: [Sip] SIP WG - 5 - Last Call Open Discussion - > > draft-ietf-sip-refer-02.txt > > > > > > I don't believe there has been any conclusion posted about security > > aspects of the Referred-By header, which I raised as issues in my > > initial review of this draft. > > > > Without an adequate mechanism to verify the information in > > the Referred-By > > header, and to verify the timeliness of that information, the > > header is > > worse than useless. It should be removed from the draft. > > > > To repeat the problem, consider three parties, A, B, and C, where > > A sends a REFER to B, causing B to send an INVITE to C. Procedures > > exist whereby B can authenticate A; procedures also exist whereby > > C can authenticate B. > > > > However, nothing prevents B from including a bogus > Referred-By header > > in its INVITE request to C. Nothing prevents B from including a > > previously-valid-but-expired Referred-By header in its INVITE (i.e. > > a form of replay attack). Anything done by C based on information > > in the Referred-By header may be incorrect or harmful. > > Anything done by C based on information in the Referred-By header > would be determined by the application using the primative. The first > application we're talking about is Transfer. The current proposal > is to leave REFER as is, and specify usage of the parameters available > on the Referred-By header to get exactly the protection you > describe for > the transfer application. > > Are you objecting to this approach? If we actually remove the header, > we will be left without a conduit between the REFER and the triggered > action to include such procection mechanisms... > > RjS > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:45:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03903 for ; Wed, 2 Jan 2002 08:45:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07542 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:45:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07283; Wed, 2 Jan 2002 08:35:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07231 for ; Wed, 2 Jan 2002 08:35:42 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03745 for ; Wed, 2 Jan 2002 08:35:39 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02AgGK16217 for ; Wed, 2 Jan 2002 11:42:16 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02AgGhO011944 for ; Wed, 2 Jan 2002 12:42:16 +0200 (EET) Message-ID: <3C32E467.A31FEF80@lmf.ericsson.se> Date: Wed, 02 Jan 2002 12:43:51 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Open Issue #325: Interop with tagless BYE References: <3C32A019.2050408@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, This is (a little) related to the issue #140. I KNOW the case is closed, but a while ago I asked if nodes really MUST care about the To- and From header URLs for call matching, or if the tags are enough? Ok, that won't solve this issue, but it would bring up the following question: if one doesn't have to care about the To- and From header URLs, for BYE it could be said that one doesn't have to care about the tags either - if they are not included (if there are tags, they must be treated, since the client wants to terminate only a specific leg). Also, it's not only about if the UAS accepts the BYE or not. Are intermediate proxies able to fork it correct? Will they assume that it shall be forked like the INVITE, like a CANCEL? Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > Bis-05 is clear that if you get a BYE outside of a dialog, you reject > it. This > is self-consistent with BYE handling in bis-05. > > However, there may be backwards compatibility issues. It is possible > that there > exist UAs that still send BYE on hangup before the final response to > invite is > received, and likely that these are sent without To tags. This means > that the > UAS will get a BYE outside of a dialog. If it ignores this BYE, the call > will > not be hungup. > > Do we need to worry about this? > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:45:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03918 for ; Wed, 2 Jan 2002 08:45:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07556 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:45:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06552; Wed, 2 Jan 2002 08:29:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06459 for ; Wed, 2 Jan 2002 08:29:15 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03545 for ; Wed, 2 Jan 2002 08:29:11 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02CgZJ17567 for ; Wed, 2 Jan 2002 13:42:35 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02CgZhO019835 for ; Wed, 2 Jan 2002 14:42:35 +0200 (EET) Message-ID: <3C33009A.6B232FF9@lmf.ericsson.se> Date: Wed, 02 Jan 2002 14:44:10 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi John, Are you talking about fragmentation on the SIP level, or on the IP/UDP level? I assume you talk about the IP/UDP level, and in that case I don't understand what the SIP application has to do with it. The SIP application shouldn't care if IP packages are fragmented (after all, even if the SIP node itself doesn't do fragmentation, packages may be fragmented by intermediate routers anyway...). If fragments are lost, the UDP checksum will inform the receiver about that. And, the reason we have re-transmits when using UDP is to make sure the receiver will get a "complete" message, in case messages/fragments are lost in the network... Regards, Christer Holmberg Ericsson Finland John.Hearty@Level3.com wrote: > > Hmmm. I'd say all your implementations that support reassembling > fragmented SIP risk problems if there is packet loss. They are making up > for non-compliant devices that are fragmenting the SIP messages (see bis-05 > section 7.5). SIP over unreliable transports should be in one datagram to > maintain the reliability mechanisms built into SIP. If you fragment the > message, the reliability may be lost. > > John Hearty > Level3 > > > -----Original Message----- > > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > > Sent: Friday, December 28, 2001 1:18 AM > > To: sip@ietf.org > > Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations > > > > > > i have nothing against introducing an error response for truncated UDP > > messages, but whatever the new spec will say should not make existing > > implementations that support large udp packets non-compliant. > > > > i have in active use half a dozen different sip phone, > > proxies and media > > gateway controllers and all of them today send and receive > > sip messages > > in udp packets that are larger than 1500 bytes. their network driver > > simply ip fragments and reassembles a packet if it doesn't fit into a > > 1500 byte ethernet frame. almost a year ago i found one ip phone that > > didn't support reception of framented udp packets, but that > > was promptly > > fixed, when i reported the issue. > > > > if the new version of the spec will say (as jonathan > > suggested) "if the > > request is larger than 1500 bytes, you MUST use TCP to send it", then > > such a statement would make all off-the-shelf sip entities that are > > currently in use in my network non-compliant, which would be > > a VERY bad > > idea. > > > > -- juha > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:45:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03934 for ; Wed, 2 Jan 2002 08:45:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07570 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:45:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06609; Wed, 2 Jan 2002 08:29:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06566 for ; Wed, 2 Jan 2002 08:29:22 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03547 for ; Wed, 2 Jan 2002 08:29:17 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02AIMJ04202 for ; Wed, 2 Jan 2002 11:18:22 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02AIMhO010583 for ; Wed, 2 Jan 2002 12:18:22 +0200 (EET) Message-ID: <3C32DECE.6FB5AD21@lmf.ericsson.se> Date: Wed, 02 Jan 2002 12:19:58 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C2AC76E.3050208@dynamicsoft.com> <3C319BA1.D5D15074@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Some more issues on this. First, if the UAS has NOT (maybe because of media direction reasons etc) noticed the media failure the re-INVITE will be treated like a any re-INVITE, and if the SDP hasn't changed it will simply trigger a response... Second, IF the UAS has noticed the media failure it would also send a re-INVITE (possible with new SDP parameters, if new resources must be reserved) and we may get a re-INVITE race condition (see Open Issue #139). Third, if a intermediate SIP node (eg a SIP proxy controlling a media server) detects the failure, it won't be able to do anything. Should it then simply wait for the re-INVITE? Fourth, I think that in many (most?) cases the failure will be in the network, on a IP-or-lower level, and not in the SIP end nodes, in which cases a re-INVITE won't help anyway... Just my thoughts... Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > > Hi, > > >>However, if the nodes are separated, and eg MGCP/H.248 is used between > >>them, those protocols may define other actions to be taken when media > >>failures occur. For example, MGCP allows the media handler to RELEASE > >>the call if the media "connection" is lost, so to be able to > >>re-establish the session a whole NEW session must be setup. > >> > >I think that is wrong. I don't think the media handler can release the > >call, it can only inform the MGC of errors. > > That is true for H.248, but when using MGCP the media handler (ie the > Media Gateway) IS allowed to release the connection and send DLCX > (DeleteConnection) to the call controller (ie the Media Gateway > Controller). > > Also, when using an ATM bearer there are some additional H.248 events > indicating bearer failures. Right now I don't remember if any of those > events indicate that the connection has actually been released, but I'll > look into that... > > >That would be the "of" event in the MGCP RTP package. As such, the MGC can decide what to do, and in > >this case, the spec would say it SHOULD do a re-INVITE. > >>And, if the node is a gateway it may not be able to set up a new session in the > >>first place, since it's an end-user of either "side" of the gateway > >>which set up the session. > >> > > > >This makes no sense whatsoever to me. The UA is in the gateway, and the > >RTP session handler is in the gateway. If a gateway detects failure of > >RTP, it can certainly send a re-INVITE. > > Yes, IF all the resources on the PSTN (or whatever gateway we're using) > are still reserved, and the session has been "lost" only from a SIP > point of view. But, if some of the PSTN resources has also been > lost/released, sending a re-INVITE won't help, since the session would > have to be re-established also on the PSTN side. > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:46:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03951 for ; Wed, 2 Jan 2002 08:46:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07591 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:46:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07262; Wed, 2 Jan 2002 08:35:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07223 for ; Wed, 2 Jan 2002 08:35:41 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03743 for ; Wed, 2 Jan 2002 08:35:38 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g026SUK15259; Wed, 2 Jan 2002 07:28:30 +0100 (MET) Received: from lmf.ericsson.se (E0000864A0D27.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g026SUhO026782; Wed, 2 Jan 2002 08:28:30 +0200 (EET) Message-ID: <3C32A8F0.DF70D259@lmf.ericsson.se> Date: Wed, 02 Jan 2002 08:30:08 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #325: Interop with tagless BYE References: <3C32A019.2050408@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, This is (a little) related to the issue #140. I KNOW the case is closed, but a while ago I asked if nodes really MUST care about the To- and From header URLs for call matching, or if the tags are enough? Ok, that won't solve this issue, but it would bring up the following question: if one doesn't have to care about the To- and From header URLs, for BYE it could be said that one doesn't have to care about the tags either - if they are not included (if there are tags, they must be treated, since the client wants to terminate only a specific leg). Also, it's not only about if the UAS accepts the BYE or not. Are intermediate proxies able to fork it correct? Will they assume that it shall be forked like the INVITE, like a CANCEL? Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > Bis-05 is clear that if you get a BYE outside of a dialog, you reject > it. This > is self-consistent with BYE handling in bis-05. > > However, there may be backwards compatibility issues. It is possible > that there > exist UAs that still send BYE on hangup before the final response to > invite is > received, and likely that these are sent without To tags. This means > that the > UAS will get a BYE outside of a dialog. If it ignores this BYE, the call > will > not be hungup. > > Do we need to worry about this? > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 08:52:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04089 for ; Wed, 2 Jan 2002 08:52:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07675 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 08:52:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07152; Wed, 2 Jan 2002 08:34:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07120 for ; Wed, 2 Jan 2002 08:34:08 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03725 for ; Wed, 2 Jan 2002 08:34:05 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02DXhJ24915; Wed, 2 Jan 2002 14:33:43 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02DXghO023240; Wed, 2 Jan 2002 15:33:42 +0200 (EET) Message-ID: <3C330C35.3483407C@lmf.ericsson.se> Date: Wed, 02 Jan 2002 15:33:41 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C32A2DC.6050705@dynamicsoft.com> <3C3300C6.43EFE413@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I guess the next question could then be: should that outgoing proxy be allowed to "map" the tel-URL from the PDA to a SIP-URL, and insert its domain name in the host part? I KNOW that is not currently allowed by the spec, and it would require some extra (NAT alike) functionality in the proxy to map between the URLs, but then the receiver(s) would know from which domain the message comes. PDA outbound proxy UAS ---tel:1234---> -sip:1234@proxy.manhattan.com-> Regards, Christer Holmberg Ericsson Finland "Henning G. Schulzrinne" wrote: > > Jonathan Rosenberg wrote: > > > > THe spec is silent on what to do when a user enters just a telephone > > number at a > > SIP UA. Does the UA generate a SIP URL using the default domain of the > > UA, or > > does it generate a tel URL? Do we even need to say anything about this? We > > might, since otherwise, a UA that always uses tel won't interoperate with a > > proxy which doesn't support tel at all. > > I don't expect users to actually enter "tel:", so the UA is likely to > make the choice based on implementation heuristics. One problem is that > the UA may have very limited knowledge as to where it is. If I carry my > PDA SIP phone to a new domain (say, a hotel), it knows its home domain > (say, cs.columbia.edu), the IP address of its local "outbound" proxy > (via DHCP) and that's it. > > In that case, both possible choices seem reasonable when entering > 939-7000: > > - make it 9397000@cs.columbia.edu, meaning that the number is > interpreted in my home domain > - make it tel:9397000, meaning the number is interpreted in my visited > domain, by the outbound proxy > > Clearly, the results are going to be rather different if I'm outside > Manhattan. > > For 911 and 411-style phone numbers, the latter is the only viable > option until we have a better infrastructure in place. In any event, UAs > should probably be prepared to deal with proxies that can't handle tel > URLs. Currently, our ability to say unambiguously "URL scheme not > supported" is rather weak. 404 doesn't quite fit. This may suggest > either a new status code or Warning header value. > > The best we can probably do is to allow users to choose and have the UA > deal with the error case by switching to home resolution. > > > > > I would probably argue that when a user enters an unqualified name to be > > called, > > the UA generates a SIP URL, filling in the domain with its domain of > > administration. This means that no matter what is entered, it is the > > domain of > > the UA which is the one that needs to figure out how to interpret it. > > This makes > > it work for things beyond phone numbers. > > > > Either way, the spec should talk about this. > > > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 09:13:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04372 for ; Wed, 2 Jan 2002 09:13:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08541 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 09:13:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07876; Wed, 2 Jan 2002 08:59:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07845 for ; Wed, 2 Jan 2002 08:59:38 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04168 for ; Wed, 2 Jan 2002 08:59:35 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g02DwrJ22403; Wed, 2 Jan 2002 14:58:53 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g02DwqhO024831; Wed, 2 Jan 2002 15:58:52 +0200 (EET) Message-ID: <3C33121B.7F515827@lmf.ericsson.se> Date: Wed, 02 Jan 2002 15:58:51 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Bobby Sardana , Jonathan Rosenberg , Dean Willis , Michael Thomas , John.Hearty@level3.com, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> <3C3292F8.9090109@dynamicsoft.com> <3C32A234.FA19EF8E@obsoft.com> <15410.45087.197490.178067@harjus.eng.song.fi> <3C32BED9.9BFF4905@lmf.ericsson.se> <15410.49836.567991.868232@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >i agree with christer in that 499 will mess things up very badly. if we >can't make sip transport independent, i.e., the *sip* entity should not >care how it got a message, then it was a mistake to allow udp in the >first place and we should deprecate it. I agree. I think the operator should be able to configure his nodes to use whatever transport protocol he wants, depending on network capabilities (maximum UDP size, delay, load etc), media (affects the SDP message body length) etc etc etc. I do NOT think the spec should define response codes and complicated rules etc how one must "switch" between different transport protocols etc. The good thing about having a transport independent protocol is that one can choose the transport mechanism (UDP, TCP, SCTP, whatever is defined in the future) he wants - so let's keep it that way. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 09:47:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04836 for ; Wed, 2 Jan 2002 09:47:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09640 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 09:47:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09481; Wed, 2 Jan 2002 09:34:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09377 for ; Wed, 2 Jan 2002 09:34:35 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04689 for ; Wed, 2 Jan 2002 09:34:27 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g02EXpu19022; Wed, 2 Jan 2002 09:33:52 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g02EXbl02157; Wed, 2 Jan 2002 14:33:37 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 14:32:44 -0000 Message-ID: From: "Mark Watson" To: "'Jonathan Rosenberg'" , Flemming Andreasen Cc: brett@broadsoft.com, sip@ietf.org Subject: RE:[Sip] Open Issue #188: Reply-To Date: Wed, 2 Jan 2002 14:32:38 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1939A.53F61F50" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1939A.53F61F50 Content-Type: text/plain Jonathan, I can't see how the two mechanisms are orthogonal. Reply-To: seems to be a straight sub-set of the functionality in Remote-Party-ID in privacy-02. Anyway, it's your call. If it's closed, it's closed. I am a little surprised at the enthusiasm for specific solutions over a generic one. I thought there was considerable value in a generic solution to this problem which would avoid the need to re-invent the machinery attached with communicating identity information every time we encounter a new requirement. In particular the machinery associated with carrying private information within a trusted domain (although this doesn't apply to Reply-To). There *is* a difference between defining new individual headers (e.g. Reply-To) versus defining new types in a more generic header (aka Remote-Party-ID), and that is that the latter offers some forwards compatibility advantages - I can be sure that (if RPI is supported) then the new RPI type header will receive the generic RPI processing even at nodes which do not support the new type. In contrast, a new header will just be ignored. Regards, Mark Watson Nortel Networks > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 27 December 2001 03:58 > To: Flemming Andreasen > Cc: Watson, Mark [MDN05:EP10:EXCH]; brett@broadsoft.com; sip@ietf.org > Subject: Re: [Sip] Open Issue #188: Reply-To > > > Mark, Flemming, > > The issue of whether or not to add the "return" type back to > the privacy > spec is, really, orthogonal to this particular issue, which > is whether > to have a Reply-To header in SIP. Adding Reply-To to sip perhaps adds > more fire to the issue, but it remains orthogonal. > > Consensus at IETF 52 was to add it this header. On this list, we had > emails of support from Dean Willis, Alan Johnston, and Vijay Gurbani. > There was support, coupled with questions, from Brett Tate. > > I think this represents sufficient rough consensus. I am therefore > declaring this issue closed, and we will add a Reply-To header to sip > with identical meaning to the usage in email. > > -Jonathan R. > > Flemming Andreasen wrote: > > > > > Mark Watson wrote: > > > > > >>A Reply-To identity supplied by the user has to be treated with a > >>certain amount of caution, since the user could include any identity > >>at all. There are obvious scams where people send out calls with a > >>Reply-To of some premium rate number etc. > >> > >>But this is the case with lots of e2e information - as long as the > >>status of the information is clear, there should not be a problem > >>(i.e. 'user beware') > >> > >>However, it shows that a Reply-To identity which has in > some way been > >>verified by the outgoing proxy would have some value. Indeed, the > >>ability to have some network-vouched-for Reply-To identity is a > >>value-added service in itself that the outgoing proxy can provide. > >> > >> > > > > Anything can be a value-added service, but where do we draw > the line ? I > > could make the exact same arguments for e.g. a Contact > header and hence > > we should start providing network authenticated Contact > headers. We can > > probably find lots more if we start looking. Unless we can > find a good > > real-life example where this kind of functionality would be > important, > > I'd leave it out. > > > > > >>The intention of the RPI 'return' type was to provide both (user > >>provided, and network verified). > >> > > > > I'm not so sure about the network verified part. I think we simply > > started using the RPI for all kinds of identity information > with little > > consideration as to whether it made sense to have it > authenticated or > > not. The privacy-03 draft has corrected this my only letting the RPI > > header apply to identity information that should be verified by the > > network. > > > > > >>It seems to me that a wheel has been removed from the privacy draft > >>and half of it is being re-invented. > >> > > > >>I thought the aim of PRI was to be generic, so that one capability > >>could be re-used whenever a similar requirement emerged. > >> > >> > > > > Right, however we tried refining it to only address network > > authenticated identity information. You could of course > define another > > similar header that addressed not-network authenticated identity > > information, but there's not much difference between defining new > > individual headers (e.g. Reply-To) versus defining new > types in a more > > generic typed "user-provided identity" header (ala Remote-Party-ID). > > > > -- Flemming > > > > > > > >>Just a final point on IPR - AFAIK you don't get IPR on a > syntax. So if > >>there is IPR on the RPI header, there would be IPR on other syntaxes > >>for the same thing e.g. Reply-To, From etc. I would doubt that there > >>is any real IPR on these things, as identities of these kinds have > >>been carried in the PSTN for years. > >> > >>...Mark > >> > >>-----Original Message----- > >>From: Flemming Andreasen [mailto:fandreas@cisco.com] > >>Sent: 10 December 2001 06:16 > >>To: Jonathan Rosenberg > >>Cc: 'brett@broadsoft.com'; sip@ietf.org > >>Subject: Re: [Sip] Open Issue #188: Reply-To > >> > >>The old privacy-02 draft had a "return" rpi-id-type defined just for > >>this, > >>however with the refined scope in the new privacy-03 draft, > which only > >>addresses > >>network authenticated (and provided) identity information, it was > >>removed. Since > >>the UA is presumably the one that determines where it would like > >>return calls to > >>go, another header would make sense. Privacy of such a header is > >>trivially > >>handled by the UA by simply not supplying it (recall that the reason > >>for > >>encrypting the Remote-Party-ID rather than just removing it is to > >>allow for > >>things like call trace), unless you are looking for some kind of > >>"scoped" > >>privacy (I hope not). I agree that simply adding a Reply-To > header to > >>bis for > >>this would make sense. > >> > >>-- Flemming > >> > >>Jonathan Rosenberg wrote: > >> > >> > >>> > >>>>-----Original Message----- > >>>>From: Brett Tate [mailto:brett@broadsoft.com] > >>>>Sent: Friday, December 07, 2001 4:21 AM > >>>>To: sip@ietf.org > >>>>Subject: RE: [Sip] Open Issue #188: Reply-To > >>>> > >>>> > >>>>>Proposal: > >>>>> > >>>>>Its simple. Its compatible. Its well understood. Its going to > >>>>>really be > >>>>>needed for MESSAGE, probably other things. Let us take the > >>>>>simple route and > >>>>>add it. > >>>>> > >>>>It seems like an ideal candidate for a > >>>>new extension draft or a new version of > >>>>sip-privacy. > >>>> > >>>The question is whether this is trivial enough to just put into bis > >>> > >>rather > >> > >>>than write a separate 1 page I-D for it. sip-privacy is, I think, > >>> > >>different. > >> > >>>More below. > >>> > >>> > >>>>What is its relationship to >From and > >>>>Remote-Party-ID? > >>>> > >>>>From is who sent the request. > >>>Reply-To is to whom you should call-back later if you want to talk > >>> > >>again. > >> > >>>Not necessarily the same, just as they aren't the same in email. > >>> > >>>Remote-Party-ID provides network authenticated identities. Reply-To > >>> > >>is > >> > >>>provided by the client. If the network wanted to provide what it > >>> > >>believes is > >> > >>>the true reply-to address, it would, in theory, insert a > R-P-ID with > >>> > >>id-type > >> > >>>"reply-to" or some other such thing. However, I don't > think there is > >>> > >>much > >> > >>>value in that. Who cares what the network provider thought your > >>> > >>reply-to > >> > >>>should really be? > >>> > >>> > >>>>How many entries can it contain? > >>>> > >>>One. > >>> > >>> > >>>>If more > >>>>than 1, should something like a q-value > >>>>be present to communicate the meaning of > >>>>more than 1 value being present? > >>>> > >>>>Should it contain an expiration value? > >>>> > >>>No. KISS. If its good enough for email, its good enough for us. > >>> > >>> > >>>>Should it have a similar definition to > >>>>Remote-Party-ID so that privacy and trust > >>>>issues can be communicated? > >>>> > >>>There are privacy implications, yes. I don't think we need a new > >>> > >>R-P-ID > >> > >>>type, as I discuss above, but if privacy is requested, I would > >>> > >>imagine that > >> > >>>the reply-to would be stripped at the edge, else encrypted or some > >>> > >>other > >> > >>>such thing, as R-P-ID would. > >>> > >>>-Jonathan R. > >>>--- > >>>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > >>>Chief Scientist First Floor > >>>dynamicsoft East Hanover, NJ 07936 > >>>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>>http://www.jdrosen.net PHONE: (973) 952-5000 > >>>http://www.dynamicsoft.com > >>> > >>>_______________________________________________ > >>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > >>>This list is for NEW development of the core SIP Protocol > >>>Use sip-implementors@cs.columbia.edu for questions on current sip > >>>Use sipping@ietf.org for new developments on the application of sip > >>> > >>-- > >>Flemming Andreasen > >>Cisco Systems > >> > >> > >> > >> > >>_______________________________________________ > >>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sipping@ietf.org for new developments on the application of sip > >> > > > > -- > > Flemming Andreasen > > Cisco Systems > > > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > ------_=_NextPart_001_01C1939A.53F61F50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE:[Sip] Open Issue #188: Reply-To

Jonathan,

I can't see how the two mechanisms are orthogonal. = Reply-To: seems to be a straight sub-set of the functionality in = Remote-Party-ID in privacy-02.

Anyway, it's your call. If it's closed, it's = closed.

I am a little surprised at the enthusiasm for = specific solutions over a generic one.

I thought there was considerable value in a generic = solution to this problem which would avoid the need to re-invent the = machinery attached with communicating identity information every time = we encounter a new requirement. In particular the machinery associated = with carrying private information within a trusted domain (although = this doesn't apply to Reply-To).

There *is* a difference between defining new = individual headers (e.g. Reply-To) versus defining new types in a more = generic header (aka Remote-Party-ID), and that is that the latter = offers some forwards compatibility advantages - I can be sure that (if = RPI is supported) then the new RPI type header will receive the generic = RPI processing even at nodes which do not support the new type. In = contrast, a new header will just be ignored.

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 27 December 2001 03:58
> To: Flemming Andreasen
> Cc: Watson, Mark [MDN05:EP10:EXCH]; = brett@broadsoft.com; sip@ietf.org
> Subject: Re: [Sip] Open Issue #188: = Reply-To
>
>
> Mark, Flemming,
>
> The issue of whether or not to add the = "return" type back to
> the privacy
> spec is, really, orthogonal to this particular = issue, which
> is whether
> to have a Reply-To header in SIP. Adding = Reply-To to sip perhaps adds
> more fire to the issue, but it remains = orthogonal.
>
> Consensus at IETF 52 was to add it this header. = On this list, we had
> emails of support from Dean Willis, Alan = Johnston, and Vijay Gurbani.
> There was support, coupled with questions, from = Brett Tate.
>
> I think this represents sufficient rough = consensus. I am therefore
> declaring this issue closed, and we will add a = Reply-To header to sip
> with identical meaning to the usage in = email.
>
> -Jonathan R.
>
> Flemming Andreasen wrote:
>
> >
> > Mark Watson wrote:
> >
> >
> >>A Reply-To identity supplied by the = user has to be treated with a
> >>certain amount of caution, since the = user could include any identity
> >>at all. There are obvious scams where = people send out calls with a
> >>Reply-To of some premium rate number = etc.
> >>
> >>But this is the case with lots of e2e = information - as long as the
> >>status of the information is clear, = there should not be a problem
> >>(i.e. 'user beware')
> >>
> >>However, it shows that a Reply-To = identity which has in
> some way been
> >>verified by the outgoing proxy would = have some value. Indeed, the
> >>ability to have some = network-vouched-for Reply-To identity is a
> >>value-added service in itself that the = outgoing proxy can provide.
> >>
> >>
> >
> > Anything can be a value-added service, but = where do we draw
> the line ? I
> > could make the exact same arguments for = e.g. a Contact
> header and hence
> > we should start providing network = authenticated Contact
> headers. We can
> > probably find lots more if we start = looking. Unless we can
> find a good
> > real-life example where this kind of = functionality would be
> important,
> > I'd leave it out.
> >
> >
> >>The intention of the RPI 'return' type = was to provide both (user
> >>provided, and network verified).
> >>
> >
> > I'm not so sure about the network verified = part. I think we simply
> > started using the RPI for all kinds of = identity information
> with little
> > consideration as to whether it made sense = to have it
> authenticated or
> > not. The privacy-03 draft has corrected = this my only letting the RPI
> > header apply to identity information that = should be verified by the
> > network.
> >
> >
> >>It seems to me that a wheel has been = removed from the privacy draft
> >>and half of it is being = re-invented.
> >>
> >
> >>I thought the aim of PRI was to be = generic, so that one capability
> >>could be re-used whenever a similar = requirement emerged.
> >>
> >>
> >
> > Right, however we tried refining it to = only address network
> > authenticated identity information. You = could of course
> define another
> > similar header that addressed not-network = authenticated identity
> > information, but there's not much = difference between defining new
> > individual headers (e.g. Reply-To) versus = defining new
> types in a more
> > generic typed "user-provided = identity" header (ala Remote-Party-ID).
> >
> > -- Flemming
> >
> >
> >
> >>Just a final point on IPR - AFAIK you = don't get IPR on a
> syntax. So if
> >>there is IPR on the RPI header, there = would be IPR on other syntaxes
> >>for the same thing e.g. Reply-To, From = etc. I would doubt that there
> >>is any real IPR on these things, as = identities of these kinds have
> >>been carried in the PSTN for = years.
> >>
> >>...Mark
> >>
> >>-----Original Message-----
> >>From: Flemming Andreasen [mailto:fandreas@cisco.com]=
> >>Sent: 10 December 2001 06:16
> >>To: Jonathan Rosenberg
> >>Cc: 'brett@broadsoft.com'; = sip@ietf.org
> >>Subject: Re: [Sip] Open Issue #188: = Reply-To
> >>
> >>The old privacy-02 draft had a = "return" rpi-id-type defined just for
> >>this,
> >>however with the refined scope in the = new privacy-03 draft,
> which only
> >>addresses
> >>network authenticated (and provided) = identity information, it was
> >>removed. Since
> >>the UA is presumably the one that = determines where it would like
> >>return calls to
> >>go, another header would make sense. = Privacy of such a header is
> >>trivially
> >>handled by the UA by simply not = supplying it (recall that the reason
> >>for
> >>encrypting the Remote-Party-ID rather = than just removing it is to
> >>allow for
> >>things like call trace), unless you are = looking for some kind of
> >>"scoped"
> >>privacy (I hope not). I agree that = simply adding a Reply-To
> header to
> >>bis for
> >>this would make sense.
> >>
> >>-- Flemming
> >>
> >>Jonathan Rosenberg wrote:
> >>
> >>
> >>>
> >>>>-----Original = Message-----
> >>>>From: Brett Tate [mailto:brett@broadsoft.com]
> >>>>Sent: Friday, December 07, 2001 = 4:21 AM
> >>>>To: sip@ietf.org
> >>>>Subject: RE: [Sip] Open Issue = #188: Reply-To
> >>>>
> >>>>
> >>>>>Proposal:
> >>>>>
> >>>>>Its simple. Its compatible. = Its well understood. Its going to
> >>>>>really be
> >>>>>needed for MESSAGE, = probably other things. Let us take the
> >>>>>simple route and
> >>>>>add it.
> >>>>>
> >>>>It seems like an ideal = candidate for a
> >>>>new extension draft or a new = version of
> >>>>sip-privacy.
> >>>>
> >>>The question is whether this is = trivial enough to just put into bis
> >>>
> >>rather
> >>
> >>>than write a separate 1 page I-D = for it. sip-privacy is, I think,
> >>>
> >>different.
> >>
> >>>More below.
> >>>
> >>>
> >>>>What is its relationship to = >From and
> >>>>Remote-Party-ID?
> >>>>
> >>>>From is who sent the = request.
> >>>Reply-To is to whom you should = call-back later if you want to talk
> >>>
> >>again.
> >>
> >>>Not necessarily the same, just as = they aren't the same in email.
> >>>
> >>>Remote-Party-ID provides network = authenticated identities. Reply-To
> >>>
> >>is
> >>
> >>>provided by the client. If the = network wanted to provide what it
> >>>
> >>believes is
> >>
> >>>the true reply-to address, it = would, in theory, insert a
> R-P-ID with
> >>>
> >>id-type
> >>
> >>>"reply-to" or some other = such thing. However, I don't
> think there is
> >>>
> >>much
> >>
> >>>value in that. Who cares what the = network provider thought your
> >>>
> >>reply-to
> >>
> >>>should really be?
> >>>
> >>>
> >>>>How many entries can it = contain?
> >>>>
> >>>One.
> >>>
> >>>
> >>>>If more
> >>>>than 1, should something like a = q-value
> >>>>be present to communicate the = meaning of
> >>>>more than 1 value being = present?
> >>>>
> >>>>Should it contain an expiration = value?
> >>>>
> >>>No. KISS. If its good enough for = email, its good enough for us.
> >>>
> >>>
> >>>>Should it have a similar = definition to
> >>>>Remote-Party-ID so that privacy = and trust
> >>>>issues can be = communicated?
> >>>>
> >>>There are privacy implications, = yes. I don't think we need a new
> >>>
> >>R-P-ID
> >>
> >>>type, as I discuss above, but if = privacy is requested, I would
> >>>
> >>imagine that
> >>
> >>>the reply-to would be stripped at = the edge, else encrypted or some
> >>>
> >>other
> >>
> >>>such thing, as R-P-ID would.
> >>>
> >>>-Jonathan R.
> >>>---
> >>>Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> >>>Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = >>>dynamicsoft        &= nbsp;           &= nbsp;            = East Hanover, NJ 07936
> = >>>jdrosen@dynamicsoft.com      &= nbsp;           &= nbsp;  FAX:   (973) 952-5050
> >>>http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> >>>http://www.dynamicsoft.com
> >>>
> = >>>_______________________________________________
> >>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> >>>This list is for NEW development of = the core SIP Protocol
> >>>Use = sip-implementors@cs.columbia.edu for questions on current sip
> >>>Use sipping@ietf.org for new = developments on the application of sip
> >>>
> >>--
> >>Flemming Andreasen
> >>Cisco Systems
> >>
> >>
> >>
> >>
> = >>_______________________________________________
> >>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> >>This list is for NEW development of the = core SIP Protocol
> >>Use sip-implementors@cs.columbia.edu = for questions on current sip
> >>Use sipping@ietf.org for new = developments on the application of sip
> >>
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >
> >
>
>
> --
> Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
> Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;      East Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;        FAX: (973) = 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
>

------_=_NextPart_001_01C1939A.53F61F50-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 11:13:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06118 for ; Wed, 2 Jan 2002 11:13:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11871 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 11:13:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11337; Wed, 2 Jan 2002 10:57:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11306 for ; Wed, 2 Jan 2002 10:57:41 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05923 for ; Wed, 2 Jan 2002 10:57:37 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g02Fvdt12509; Wed, 2 Jan 2002 10:57:39 -0500 (EST) Received: from lucent.com (pctla2 [135.3.130.26]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA10876; Wed, 2 Jan 2002 10:57:37 -0500 (EST) Message-ID: <3C332D3F.A9A67146@lucent.com> Date: Wed, 02 Jan 2002 10:54:39 -0500 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #342: SDP in 488 References: <3C32A10D.3030006@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------60841C25A3475F63552B61DD" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------60841C25A3475F63552B61DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Actually I think that this IS in bis-05. 22.41 near the end states: "If the warning is caused by the session description, the status response SHOULD include a session description similar to that included in OPTIONS responses..." And 606 (and presumably 488) "...MAY contain a list of reason in a Warning..." So I have assumed that the normal response to an INVITE with unacceptable payloads would be a 488 or 606 with Warning and therefore SHOULD contain the OPTIONS Response-like body. If this is not clear in -05, I favor adding more to make it clearly encouraged. Jonathan Rosenberg wrote: > My notes indicate that there had been agreement on the list some time > back to > allow 488 and 606 to contain SDP, formatted in the same way as an OPTIONS > response (which is also not defined at this time), in order to figure out > exactly what the capabilities were, which would help explain why the > request was > rejected. This never made it into bis, and the spec says nothing about > this at > this time. > > Do we want to add it in? > > My proposal is NO. If it hasn't been missed yet, its a sign its not that > critical. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------60841C25A3475F63552B61DD Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard --------------60841C25A3475F63552B61DD-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 2 11:36:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06587 for ; Wed, 2 Jan 2002 11:36:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA12497 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 11:36:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11933; Wed, 2 Jan 2002 11:16:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11908 for ; Wed, 2 Jan 2002 11:16:24 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06181 for ; Wed, 2 Jan 2002 11:16:22 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g02GFsE16027 for ; Wed, 2 Jan 2002 11:15:54 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 Jan 2002 16:15:53 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC351C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Scott Bradner , "'Juha Heinanen'" Cc: jdrosen@dynamicsoft.com, John.Hearty@level3.com, sip@ietf.org Subject: RE: [Sip] MAJOR Open Issue #184: Message size limitations Date: Wed, 2 Jan 2002 16:15:47 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Strictly speaking, there is no compatibility issue with this particular requirement changing to a MUST. Compatibility does not equal existing implementations are automatically compliant with new versions of specification. There are compatibility issues with what should a proxy/UAC do if it receives this new response code, as presumably many existing RFC2543 implementations will be totally unable to use TCP/SCTP as an alternative to UDP in this case. Note also that the existing bis text does not mandate support of transport protocols other that UDP at the moment, therefore there will also have to be a change in the specification in the area of this requirement as well. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Juha Heinanen[SMTP:jh@lohi.eng.song.fi] > Sent: 28 December 2001 17:18 > To: Scott Bradner > Cc: jdrosen@dynamicsoft.com; John.Hearty@level3.com; sip@ietf.org > Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations > > > anyone who is concerned with reliability or with Internet congestion > > should also prefer "MUST use TCP for packets larger than 1500" - it > > will be hard to convince the IESG that it is OK for the Internet > > to not have this a MUST > > scott, > > i'm wasting too much bandwidth on this, but my point att the time has > been that someone already has convinced IESG not to have MUST there, > because it is SHOULD in rfc2543. in some other occasions people on this > list have said that iesg requires the bis to be backwards compatible > with rfc2543, but looks like we are now relaxed from that obligation. > > -- juha > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 2 13:25:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08330 for ; Wed, 2 Jan 2002 13:25:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15668 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 13:25:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15502; Wed, 2 Jan 2002 13:07:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15461 for ; Wed, 2 Jan 2002 13:07:01 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08084 for ; Wed, 2 Jan 2002 13:07:00 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g02I6fU06776 for ; Wed, 2 Jan 2002 13:06:41 -0500 (EST) Received: from cisco.com (rtp-xdm2.cisco.com [64.102.17.79]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAJ15375; Wed, 2 Jan 2002 13:06:29 -0500 (EST) Message-ID: <3C334C25.CCBD7C9E@cisco.com> Date: Wed, 02 Jan 2002 13:06:29 -0500 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Which components of req-uri are used for hash calculation Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Which components of the request uri are included for the transaction hash computation ? In a specific instance, does CANCEL sip:abcd@proxy;maddr=1.2.3.4 SIP/2.0 match INVITE sip:abcd@proxy SIP/2.0 assuming other relevant fields are same in both requests. Thanks, Shail _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 2 15:03:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09779 for ; Wed, 2 Jan 2002 15:03:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19801 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 15:03:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18972; Wed, 2 Jan 2002 14:51:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18924 for ; Wed, 2 Jan 2002 14:51:02 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09556 for ; Wed, 2 Jan 2002 14:50:58 -0500 (EST) Received: from cowboys (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id g02KsHM28687; Wed, 2 Jan 2002 14:54:17 -0600 Message-ID: <013501c193c7$656d6e50$01000001@dynamicsoft.com> From: "Dean Willis" To: "Christer Holmberg" , References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> <3C33009A.6B232FF9@lmf.ericsson.se> Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations Date: Wed, 2 Jan 2002 13:55:14 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The problem is indeed fragmentation at the UDP level. This has two confounding effects: 1) If any fragment is lost, the whole SIP message times out and must be resent. The probability of a drop increases linearly with the fragmentation ratio. An unfortunate subeffect is that fragments following the first one are sent anyhow, so the retransmission load is at least 2x the original size and not the fragment size. This is a Big Bad for the people who are worried aboutnetwork congestion behavior -- it causes SIP (at least in the sparse many-many case) to INCREASE network load during lossy conditions rather than backing off smoothly. Immagine a connection that is running at near-capacity. A glitch occurs 2) NAT boundaries get a little strange. -- Dean ----- Original Message ----- From: "Christer Holmberg" To: Sent: Wednesday, January 02, 2002 6:44 AM Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations > > Hi John, > > Are you talking about fragmentation on the SIP level, or on the IP/UDP > level? I assume you talk about the IP/UDP level, and in that case I > don't understand what the SIP application has to do with it. The SIP > application shouldn't care if IP packages are fragmented (after all, > even if the SIP node itself doesn't do fragmentation, packages may be > fragmented by intermediate routers anyway...). > . . . _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 2 15:03:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09794 for ; Wed, 2 Jan 2002 15:03:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19816 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 15:03:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19046; Wed, 2 Jan 2002 14:52:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19015 for ; Wed, 2 Jan 2002 14:52:03 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09579 for ; Wed, 2 Jan 2002 14:52:00 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g02JpQv20585; Wed, 2 Jan 2002 11:51:26 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP25923; Wed, 2 Jan 2002 11:50:53 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA10905; Wed, 2 Jan 2002 11:51:25 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15411.25789.797557.378163@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 11:51:25 -0800 (PST) To: William Marshall Cc: mat@cisco.com, sip@ietf.org Subject: REFER and third party authorization (was: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-refer-02.txt) In-Reply-To: <200201021249.HAA22277@fish.research.att.com> References: <200201021249.HAA22277@fish.research.att.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit My tenous understanding of REFER got a bit better after reading Robert's cc-transfer draft. I believe that what we are witnessing here is perhaps a new twist on an old requirement for SIP security. That is, we'd like to have the ability for a trusted third party vouch for somebody (eg the screener vouches for the caller) which needs to be transported across sessions. I say twist because we already have a requirement via remote-party-id that we must be able to provide a means for the voucher to prove their identity. What is missing is a companion requirement that that identity may also be cut from one SIP message and pasted into another, which is essentially what referred-by needs (eg, the screener needs to send something to the caller which the callee can determine was legitimately created by the screener). There are obvious replay issues here since we do not want to create an immortal authorization blob, so there needs to be some means of placing a lifetime, or some other means. I think we could deal with this in a crypto-system dependent manner though (eg, each style of crypto system needs to address this requirement in some way). My suspicion is that Referred-by is just one instance of a larger desire to have trusted third party authorization, thus it would probably be prudent to generalize this beyond just referred-by to anything which would like to assert identity and authorization for a third party. Maybe a better name, in fact, would be "approved-by" since that's really what the screener seems to be doing. A few more comments inline: William Marshall writes: > Mike Thomas wrote, in part: (complete message quoted below) > > We currently don't have a way to > > authenticate RPI either, and though we intend to > > get around to fixing that eventually, it doesn't > > seem to be a burning need. > > Agreed that it is not done in the general case, but is > done for a large number of useful cases -- with a trusted > proxy forwarding requests to the UAS over TLS/IPsec and the > UAS accepting only requests from this trusted proxy. Requests > that come over other connections can be appropriately flagged > by the UAS, or rejected. Sufficient mechanism exists today > to do this. I'm not sure I find this persuasive. RPI depends on a particular model and a whole set of assumptions, namely that the only ones who participate are service providers who all trust each other (at least on this account). This is an acceptible assumption in the current PSTN, but given how easy it is go around the service provider with SIP, I'm not sure I'd count on RPI or anything else being especially trustworthy that depends on transitive trust. An analogous situation is with source spoofed IP addresses: we want operators to perform RPF checks to make it harder, but it you really, really care on the server end, you better not count on it. The upside, however, is that I think we can do a pretty decent job -- possibly including a weak test -- for both RPI and referred-by in a generalized SIP security solution. > I assume there is sufficient mechanism defined in bis-05 to do SIP > security and what is missing is the recommendations on what mechanisms > or combination of mechanisms should be used to achieve a secure system > (and it is important for the SIP security group to validate this > assumption prior to publication of bis). I don't think there is any way to do a "secure" job of either RPI or Referred-by with bis. > My main concern is that there is not enough mechanism defined in the > refer draft to do the job. There is no mechamism defined for the recipient > of an INVITE-containing-Referred-By to get any credentials from > the party that initiated the REFER. It can't send a 401/407, > because that only goes back to the party that initiated the > INVITE-containing-Referred-By. So there is a tool missing from > the toolkit, and that is the troubling part. Yes, but I think that what is missing is just a variation on the general tool we need. Mike _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 2 15:33:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10276 for ; Wed, 2 Jan 2002 15:33:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20998 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 15:33:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20460; Wed, 2 Jan 2002 15:24:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20415 for ; Wed, 2 Jan 2002 15:24:56 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10120 for ; Wed, 2 Jan 2002 15:24:53 -0500 (EST) Received: from cowboys (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id g02LSAM28799; Wed, 2 Jan 2002 15:28:11 -0600 Message-ID: <015b01c193cc$214c8940$01000001@dynamicsoft.com> From: "Dean Willis" To: "Michael Thomas" , "William Marshall" Cc: , References: <200201021249.HAA22277@fish.research.att.com> <15411.25789.797557.378163@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 14:29:06 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: REFER and third party authorization Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I believe Michael has squarely impacted the driving surface of the piercing metallic friction fastener, forcing into the visible tip of the iceberg pointed about by Bill . . . There is indeed a general problem to be solved in third-party approval. It applies to referrals, transitive gateway authorizations (call me at this gateway using these credentials), idenitification vouching, media authorization, operator services, and so on. There is probably some applicability to privacy, especially in the authority-to-override department. It could probably also apply in two-party (auth and auth) cases. The requirements as I see it are: 1) Describe the approving distinguished entity. 2) Describe precisely what is being approved (and maintain the integrity of that information). 3) Describe for what duration the approval persists. 4) Provide for verification of the approval. 5) Prevent replay of the approval. 6) Seperability from the underlying cryptographic model(s). Is this a tractable problem? I can envision tackling it using a certificate model, and some sort of element-signing mechanism, but the result is likely to be bulky. It also begins to sound much like xml-signing . . . -- Dean ----- Original Message ----- From: "Michael Thomas" . . . > > My suspicion is that Referred-by is just one > instance of a larger desire to have trusted third > party authorization, thus it would probably be > prudent to generalize this beyond just referred-by > to anything which would like to assert identity > and authorization for a third party. Maybe a > better name, in fact, would be "approved-by" since > that's really what the screener seems to be doing. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 2 15:40:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10386 for ; Wed, 2 Jan 2002 15:40:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21094 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 15:40:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20555; Wed, 2 Jan 2002 15:29:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20531 for ; Wed, 2 Jan 2002 15:29:52 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10207 for ; Wed, 2 Jan 2002 15:29:49 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g02KRd3a009486; Wed, 2 Jan 2002 15:27:39 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 2 Jan 2002 15:29:20 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E8FB@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Michael Thomas'" , William Marshall Cc: sip@ietf.org Subject: RE: REFER and third party authorization (was: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-refer-02.txt) Date: Wed, 2 Jan 2002 15:29:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > From: Michael Thomas [mailto:mat@cisco.com] > > > My tenous understanding of REFER got a bit better > after reading Robert's cc-transfer draft. I > believe that what we are witnessing here is > perhaps a new twist on an old requirement for SIP > security. That is, we'd like to have the ability > for a trusted third party vouch for somebody (eg > the screener vouches for the caller) which needs > to be transported across sessions. I say twist > because we already have a requirement via > remote-party-id that we must be able to provide a > means for the voucher to prove their identity. > What is missing is a companion requirement that > that identity may also be cut from one SIP message > and pasted into another, which is essentially what > referred-by needs (eg, the screener needs to send > something to the caller which the callee can > determine was legitimately created by the > screener). Be careful with this model - it is only one instance of the Tranferor/Transferee/Transfer-Target relationships. Transfer will be used in other scenarios besides screening. > > There are obvious replay issues here since we do > not want to create an immortal authorization blob, > so there needs to be some means of placing a > lifetime, or some other means. I think we could > deal with this in a crypto-system dependent manner > though (eg, each style of crypto system needs to > address this requirement in some way). > > My suspicion is that Referred-by is just one > instance of a larger desire to have trusted third > party authorization, thus it would probably be > prudent to generalize this beyond just referred-by > to anything which would like to assert identity > and authorization for a third party. Maybe a > better name, in fact, would be "approved-by" since > that's really what the screener seems to be doing. I follow your point for the screener case, and I think it generalizes, but there are traps in this name-game to watch out for - "approval" (authorization) is a function of more than one participant/set of policies in the general case. Here's what I see the system needing to support when A REFERs B to C given the model we've been working with to date (assume the REFERence is for a SIP INVITE). *) B needs to Authenticate A (should be baseline SIP) *) C needs to Authenticate B (should be baseline SIP) *) B must prove to C two things: (this is what's new) 1) This is the request B was asked to make 2) The identity of the originator of the REFER was A The original proposal had A hand B a blob that B forwarded to C. This blob contained the essential properties of the triggered request, a timestamp and was signed (PGP at the time) by A. C got the two proofs it needed when B included the blob in the request. Is this the kind of thing you mean when you say 3rd party authorization? > > A few more comments inline: > > William Marshall writes: > > Mike Thomas wrote, in part: (complete message quoted below) > > > We currently don't have a way to > > > authenticate RPI either, and though we intend to > > > get around to fixing that eventually, it doesn't > > > seem to be a burning need. > > > > Agreed that it is not done in the general case, but is > > done for a large number of useful cases -- with a trusted > > proxy forwarding requests to the UAS over TLS/IPsec and the > > UAS accepting only requests from this trusted proxy. Requests > > that come over other connections can be appropriately flagged > > by the UAS, or rejected. Sufficient mechanism exists today > > to do this. > > I'm not sure I find this persuasive. RPI depends > on a particular model and a whole set of > assumptions, namely that the only ones who > participate are service providers who all trust > each other (at least on this account). This is an > acceptible assumption in the current PSTN, but > given how easy it is go around the service > provider with SIP, I'm not sure I'd count on RPI > or anything else being especially trustworthy that > depends on transitive trust. An analogous > situation is with source spoofed IP addresses: we > want operators to perform RPF checks to make it > harder, but it you really, really care on the > server end, you better not count on it. > > The upside, however, is that I think we can do a > pretty decent job -- possibly including a weak > test -- for both RPI and referred-by in a > generalized SIP security solution. > > > I assume there is sufficient mechanism defined in bis-05 to do SIP > > security and what is missing is the recommendations on > what mechanisms > > or combination of mechanisms should be used to achieve a > secure system > > (and it is important for the SIP security group to validate this > > assumption prior to publication of bis). > > I don't think there is any way to do a "secure" > job of either RPI or Referred-by with bis. > > > My main concern is that there is not enough mechanism > defined in the > > refer draft to do the job. There is no mechamism defined > for the recipient > > of an INVITE-containing-Referred-By to get any credentials from > > the party that initiated the REFER. It can't send a 401/407, > > because that only goes back to the party that initiated the > > INVITE-containing-Referred-By. So there is a tool missing from > > the toolkit, and that is the troubling part. > > Yes, but I think that what is missing is just > a variation on the general tool we need. Just to make sure we're all on the same page: Bill is asking for an interactive proof between A and C (challenge based credentialling), something the original proposal for REFER didn't support - it only allowed static proofs. Are you suggesting a 3rd-party auth/auth mechanism that would allow this to be interactive or are you claiming that static proofs are sufficient? > > Mike > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 2 17:43:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12461 for ; Wed, 2 Jan 2002 17:43:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25504 for sip-archive@odin.ietf.org; Wed, 2 Jan 2002 17:43:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25337; Wed, 2 Jan 2002 17:33:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25306 for ; Wed, 2 Jan 2002 17:33:07 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12293 for ; Wed, 2 Jan 2002 17:33:02 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g02MWSv14826; Wed, 2 Jan 2002 14:32:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP29570; Wed, 2 Jan 2002 14:31:54 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA10951; Wed, 2 Jan 2002 14:32:27 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15411.35451.170440.297506@thomasm-u1.cisco.com> Date: Wed, 2 Jan 2002 14:32:27 -0800 (PST) To: Jonathan Rosenberg Cc: Jari Arkko , sip@ietf.org Subject: Re: [Sip] Issue #232: TLS v. IPSec In-Reply-To: <3C2B5268.9030709@dynamicsoft.com> References: <3C2B5268.9030709@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit So let me add one more data point here. In a fit of dementia, I hacked up a transport mode only hmac-md5 ESP-NULL which interoperates with my Linux box's freeswan IPsec. Total cost in code was about 6kbytes, and little to nothing in data. 5kb was the hmac-md5. If you can't afford this, you can't afford any crypto at all. I don't claim this is scalable. I claim that it is much better than nothing though. What would be the minimal cost for a similarly stripped down TLS? Can you even run TLS with manual keys? I didn't think so, but I could be wrong. Mike Jonathan Rosenberg writes: > > > Jari Arkko wrote: > > > > >>I think its sensible to separate the transport security into user to proxy > >>and proxy to proxy security. For proxy to proxy, TLS appears much better. > >> > > > > But here I disagree. There's a few problems in TLS as well. The main > > one from my point of view relates to very large networks (guess which > > ones?) where scalability proxy-to-proxy might be an issue.Here, IPsec > > tunnel mode and separate gateways could help a lot -- if you have an SA > > pair between all operators that is much better than an SA pair between > > each box of each operator (e.g. 1000 operators => 1M SAs; 50 proxy > > farm on each operator site => 2.5 G SAs). > > > True, tunnel mode IPSec would reduce the number of SAs. However, as we > discussed during the 3gpp ad-hoc at IETF 52, there are issues with it. > Namely, when the IPSec tunnel terminates in front of the proxy, there is > no easy way for the proxy to know WHICH peer network the message came > from. To know, it would have to look at the IP address of the source. > Now, if there are 50 proxies in each operator network, well, you are > right back to where you started in terms of scale, and the proposed > benefit of IPSec tunnel mode is lost. > > If you don't care about knowing which operator a request comes from, > then tunnel mode is better. However, note that in this case, the tunnel > isn't even running on a sip proxy, so the usage of such things would be > outside the scope of SIP. The ONLY question we need to deal with is ON A > SIP PROXY, do we say you MUST implement TLS, MAY implement IPSec, or the > other way around. > > > > > There are also other issues, > > such as the fact that an IPsec tunnel could also be used simultaneously > > for lots of other signaling protection needs > > > Same comment as above; of course you can do that, but its outside the > scope of the spec. > > > while the TLS is only useful > > for one thing. SCTP. > > > SCTP? > > > > Question: does TLS support preshared symmetric keys (which IPsec does, > > easing deployment as you don't need to deploy certs and possibly PKIs)? > > > I believe it does not. > > > > > > Also, I believe Mike Thomas posted some long list of pros and cons > > for the TLS-IPsec in SIP a while back. Perhaps we could get back to > > that list? > > > I suspect that the debates will continue without resolution, because I > think we seem to have different problems in mind. I am concerned about > cases where the proxy application needs some kind of authenticated > identity of its peer in order to make policy decisions. Since, > practically speaking, IPsec is generally done in the O/S, I think TLS is > better here if that is what you are concerned about. Others want to use > IPSec gateways, as you have suggested, between operators. Thats fine, > but its a different problem where clearly IPSec is better than TLS. I > also think its outside the scope of the spec, as I have pointed out above. > > In any case, no one has said MUST NOT use IpSec. Please let us remember > that. It is only a question of which is mandatory to implement (not the > same as mandatory to use). The primary issue here is when two proxies > from different vendors are plopped down next to each other, will they be > able to communicate securely? > > > >>It also has a workable keying solution, whereas IPSec does not at > >>this time. > >> > > > > I think this is an overly broad claim. They are working on an a new IKE > > version, > > > Thats good news, but I am worried about a security solution I can deploy > this year rather than three years from now. > > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 00:46:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18120 for ; Thu, 3 Jan 2002 00:46:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA06532 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 00:46:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05989; Thu, 3 Jan 2002 00:26:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA05958 for ; Thu, 3 Jan 2002 00:26:36 -0500 (EST) Received: from web20308.mail.yahoo.com (web20308.mail.yahoo.com [216.136.226.89]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18009 for ; Thu, 3 Jan 2002 00:26:34 -0500 (EST) Message-ID: <20020103052635.67211.qmail@web20308.mail.yahoo.com> Received: from [12.237.7.244] by web20308.mail.yahoo.com via HTTP; Wed, 02 Jan 2002 21:26:35 PST Date: Wed, 2 Jan 2002 21:26:35 -0800 (PST) From: Jasson Casey To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Difference in sip bis04/bis05 BNF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I was going through the new BNF and I had a few questions. The first is in sip bis05 line 9830: TILDE = LWS " LWS ; tilde Should the line read: TILDE = LWS "~" LWS ; tilde The second question is in sip bis05 line 9949: headers = "?" header *(" " header) The corresponding line from bis04 (1107) headers = "?" header *("&" header) Why is the ampersand no longer present? Finally, I had a question concerning (url|uri) within the to/from headers. Specifically, I am seeking clarification on the usage of to/from parameters (tag, name=value, etc). Originally, I had a concern about the difference between a url|uri parameter and a to/from parameter. In bis04 it seemed that the following "<" url|uri ">" *(to/from-params) was used to know the difference. Where in bis05 the use seems to be a bit different: name-addr = [ display-name ] LAQUOT addr-spec RAQUOT So, "<" and ">" are only used for display-name applications. If this is the new usage, then once again how do I tell the difference between a (url|uri) parameter and a (to|from) parameter. It seems that I could encounter something like the following: From: sip:bob@yahoo.com:1234;maddr=224.1.2.3;name=value;tag=1234 Is name=value a url|uri parameter or a from-param? Any clarification would be helpful. Thanks, Jasson Casey jassoncasey@yahoo.com __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 01:17:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18382 for ; Thu, 3 Jan 2002 01:17:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA15789 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 01:17:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06708; Thu, 3 Jan 2002 00:59:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06682 for ; Thu, 3 Jan 2002 00:59:52 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18269 for ; Thu, 3 Jan 2002 00:59:48 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g035xhK21833; Thu, 3 Jan 2002 06:59:44 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g035xghO004241; Thu, 3 Jan 2002 07:59:42 +0200 (EET) Message-ID: <3C33F328.462434B8@lmf.ericsson.se> Date: Thu, 03 Jan 2002 07:59:04 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> <3C33009A.6B232FF9@lmf.ericsson.se> <013501c193c7$656d6e50$01000001@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, The solution to the problem you describe is - SIP. If an operator has the problem with UDP that you describe, either in the whole of his network or between specific SIP nodes, he may configure the nodes to use TCP (or SCTP, or whatever) instead of UDP. Again, that's one of the good things of having a transport independent protocol. What we are discussing here is if the choise of transport protocol, or "switching" between transport protocols, should be done on the SIP application level (and HOW the choise shall be done) or not, and MY opinion is that it shall not. Abuot the fragmentation: does anyone have any numbers/statistics how OFTEN it will occur in a real-network scenario, and how MUCH congestion/delay it generatas? Also, WHICH messages are fragmented, and how MANY fragments are genearted? How will SIP compression affect that? How is it COMPARED to the network load generated by TCP? etc etc etc. I think there are LOST of questions to answer before doing any "radical" changes in the spec... I remember a couple of years ago, when everybody having a "SIP vs H.323" speech at some conference said that SIP is so great because (among other things) it can be used with UDP... :) Regards, Christer Holmberg Ericsson Finland Dean Willis wrote: > > The problem is indeed fragmentation at the UDP level. This has two > confounding effects: > > 1) If any fragment is lost, the whole SIP message times out and must be > resent. The probability of a drop increases linearly with the fragmentation > ratio. An unfortunate subeffect is that fragments following the first one > are sent anyhow, so the retransmission load is at least 2x the original size > and not the fragment size. This is a Big Bad for the people who are worried > aboutnetwork congestion behavior -- it causes SIP (at least in the sparse > many-many case) to INCREASE network load during lossy conditions rather than > backing off smoothly. Immagine a connection that is running at > near-capacity. A glitch occurs > > 2) NAT boundaries get a little strange. > > -- > Dean > > ----- Original Message ----- > From: "Christer Holmberg" > To: > Sent: Wednesday, January 02, 2002 6:44 AM > Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations > > > > > Hi John, > > > > Are you talking about fragmentation on the SIP level, or on the IP/UDP > > level? I assume you talk about the IP/UDP level, and in that case I > > don't understand what the SIP application has to do with it. The SIP > > application shouldn't care if IP packages are fragmented (after all, > > even if the SIP node itself doesn't do fragmentation, packages may be > > fragmented by intermediate routers anyway...). > > > > . . . _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 02:27:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26921 for ; Thu, 3 Jan 2002 02:27:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA17665 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 02:27:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17193; Thu, 3 Jan 2002 02:08:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17161 for ; Thu, 3 Jan 2002 02:08:20 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26770 for ; Thu, 3 Jan 2002 02:08:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0378HVZ006069; Thu, 3 Jan 2002 02:08:17 -0500 (EST) Message-ID: <3C340345.6090901@dynamicsoft.com> Date: Thu, 03 Jan 2002 02:07:49 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jasson Casey CC: sip@ietf.org Subject: Re: [Sip] Difference in sip bis04/bis05 BNF References: <20020103052635.67211.qmail@web20308.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jasson Casey wrote: > I was going through the new BNF and I had a few > questions. > > The first is in sip bis05 line 9830: > TILDE = LWS " LWS ; tilde > > Should the line read: > TILDE = LWS "~" LWS ; tilde Yes. This is a latex error of some sort. Thanks. > > The second question is in sip bis05 line 9949: > headers = "?" header *(" " header) > > The corresponding line from bis04 (1107) > headers = "?" header *("&" header) > > Why is the ampersand no longer present? Another latex error. Its correct in the PS/PDF. > > Finally, I had a question concerning (url|uri) within > the to/from headers. Specifically, I am seeking > clarification on the usage of to/from parameters (tag, > name=value, etc). > > Originally, I had a concern about the difference > between a url|uri parameter and a to/from parameter. > In bis04 it seemed that the following "<" url|uri ">" > *(to/from-params) was used to know the difference. > Where in bis05 the use seems to be a bit different: > > name-addr = [ display-name ] LAQUOT addr-spec RAQUOT > > So, "<" and ">" are only used for display-name > applications. What makes you say that? The usage is unchanged. > If this is the new usage, then once > again how do I tell the difference between a (url|uri) > parameter and a (to|from) parameter. It seems that I > could encounter something like the following: > > From: > sip:bob@yahoo.com:1234;maddr=224.1.2.3;name=value;tag=1234 > > Is name=value a url|uri parameter or a from-param? Nothing has changed. In the above case, maddr, name and tag would all be From parameters. Please tell me what text implies that this has changed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 02:45:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27126 for ; Thu, 3 Jan 2002 02:45:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA18397 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 02:45:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17645; Thu, 3 Jan 2002 02:27:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17620 for ; Thu, 3 Jan 2002 02:27:00 -0500 (EST) Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26915 for ; Thu, 3 Jan 2002 02:26:56 -0500 (EST) Received: from obsoft.com (localhost.localdomain [127.0.0.1]) by obsoft.com (8.11.6/8.11.6) with ESMTP id g037W8U02717; Wed, 2 Jan 2002 23:32:09 -0800 Message-ID: <3C3408F8.E2FDDFDF@obsoft.com> Date: Wed, 02 Jan 2002 23:32:08 -0800 From: Bobby Sardana Organization: ObjectSoftware, Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Jonathan Rosenberg , Dean Willis , Michael Thomas , John.Hearty@level3.com, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> <3C3292F8.9090109@dynamicsoft.com> <3C32A234.FA19EF8E@obsoft.com> <15410.45087.197490.178067@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit From an implementation's perspective, co-orelating responses from different transport types can lead to bulky UA implementations. A simple methodology, if TCP/UDP support is needed in SIP, would be: a. Use the same transport type for all downstream/upstream communication. b. When in doubt, use TCP. If we are planning to mix request/responses using TCP/UDP, then mandate only one and deprecate the other. Regards, Bobby Sardana. sardana@obsoft.com Juha Heinanen wrote: > Bobby Sardana writes: > > > Just curious, why can't the 499 be propagated all the way to the UAC with > > no intermediary (proxy) storage of responses? So if the request originated > > as UDP and the UAS cannot handle it, because of size limitations, and > > requires that a TCP request be made, just reject the request and propagate > > it (like some other errors) back to the UAC. The UAC can then originate a > > TCP request. > > just to ask again, why can't the uas use tcp to send the response even > if it got the request using udp? sip should care what the transport > protocol is. > > -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 02:48:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27202 for ; Thu, 3 Jan 2002 02:48:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA18449 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 02:48:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18278; Thu, 3 Jan 2002 02:37:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18246 for ; Thu, 3 Jan 2002 02:37:33 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27048 for ; Thu, 3 Jan 2002 02:37:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g037b0VZ006086; Thu, 3 Jan 2002 02:37:00 -0500 (EST) Message-ID: <3C340A00.2090602@dynamicsoft.com> Date: Thu, 03 Jan 2002 02:36:32 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C3300C6.43EFE413@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning G. Schulzrinne wrote: > Jonathan Rosenberg wrote: > >>THe spec is silent on what to do when a user enters just a telephone >>number at a >>SIP UA. Does the UA generate a SIP URL using the default domain of the >>UA, or >>does it generate a tel URL? Do we even need to say anything about >> > this? We > >>might, since otherwise, a UA that always uses tel won't interoperate >> > with a > >>proxy which doesn't support tel at all. >> > > I don't expect users to actually enter "tel:", Agreed. > so the UA is likely to > make the choice based on implementation heuristics. One problem is that > the UA may have very limited knowledge as to where it is. If I carry my > PDA SIP phone to a new domain (say, a hotel), it knows its home domain > (say, cs.columbia.edu), the IP address of its local "outbound" proxy > (via DHCP) and that's it. > > In that case, both possible choices seem reasonable when entering > 939-7000: > > - make it 9397000@cs.columbia.edu, meaning that the number is > interpreted in my home domain > - make it tel:9397000, meaning the number is interpreted in my visited > domain, by the outbound proxy > > Clearly, the results are going to be rather different if I'm outside > Manhattan. The problem is that, just because its digits, doesn't mean anything about whether its really a phone number. My domain may simply have handed out numeric usernames. Or, for me, "11" may be a speed dial group. Only my domain can properly interpret the username, which is why I don't see how the tel URL would work in general. Also, it seems odd that if I enter: a123 this results in one URL (a SIP URL), but if I enter: 123 this results in a tel URL. I see it much like what happens when you enter an unqualified domain name into a local resolver; the remainder of the name is filled in at the local host with the configured domain. Seems like the same logic should apply here. > > For 911 and 411-style phone numbers, the latter is the only viable > option until we have a better infrastructure in place. For 411, I don't see why its wrong to do sip:411@cs.columbia.edu, which would then realize that its information service and do whats needed. ARguably, 911 needs to be processed immediately, but I would think that the right way to do this is for the UA to recognize 911 and use a special emergency SIP URL that may not be scoped to EITHER cs.columbia.edu or be a tel URL... but I've not been following the 911 work too closely so I could be wrong here. > In any event, UAs > should probably be prepared to deal with proxies that can't handle tel > URLs. It just seems like another opportunity for interop failures and complexity. > Currently, our ability to say unambiguously "URL scheme not > supported" is rather weak. 404 doesn't quite fit. This may suggest > either a new status code or Warning header value. > > The best we can probably do is to allow users to choose and have the UA > deal with the error case by switching to home resolution. I was hoping for one mechanism rather than two... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 02:53:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27282 for ; Thu, 3 Jan 2002 02:53:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA18569 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 02:53:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18227; Thu, 3 Jan 2002 02:35:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18196 for ; Thu, 3 Jan 2002 02:35:31 -0500 (EST) Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27025 for ; Thu, 3 Jan 2002 02:35:28 -0500 (EST) Received: from obsoft.com (localhost.localdomain [127.0.0.1]) by obsoft.com (8.11.6/8.11.6) with ESMTP id g037eoU02724; Wed, 2 Jan 2002 23:40:50 -0800 Message-ID: <3C340B02.5F54BA22@obsoft.com> Date: Wed, 02 Jan 2002 23:40:50 -0800 From: Bobby Sardana Organization: ObjectSoftware, Inc X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> <3C33009A.6B232FF9@lmf.ericsson.se> <013501c193c7$656d6e50$01000001@dynamicsoft.com> <3C33F328.462434B8@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > ...... > I remember a couple of years ago, when everybody having a "SIP vs H.323" > speech at some conference said that SIP is so great because (among other > things) it can be used with UDP... :) > > Regards, > > Christer Holmberg > Ericsson Finland SIMPLE secure evolution :-) regards, Bobby Sardana. sardana@obsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 03:09:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27455 for ; Thu, 3 Jan 2002 03:09:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA19455 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 03:09:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18616; Thu, 3 Jan 2002 02:54:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18587 for ; Thu, 3 Jan 2002 02:54:36 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27302 for ; Thu, 3 Jan 2002 02:54:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g037sXVZ006090; Thu, 3 Jan 2002 02:54:34 -0500 (EST) Message-ID: <3C340E1E.7040705@dynamicsoft.com> Date: Thu, 03 Jan 2002 02:54:06 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Shail Bhatnagar CC: sip@ietf.org Subject: Re: [Sip] Which components of req-uri are used for hash calculation References: <3C334C25.CCBD7C9E@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > Which components of the request uri are included > for the transaction hash computation ? > > In a specific instance, does > > CANCEL sip:abcd@proxy;maddr=1.2.3.4 SIP/2.0 > > match > > INVITE sip:abcd@proxy SIP/2.0 > > assuming other relevant fields are same in > both requests. Well, based on a strict reading of bis right now, they would match. Thats because the r-uri in the CANCEL has to equal that in the INVITE. SIP URL equality does not take maddr into account at the moment, so they would be equal. HOWEVER, I believe that this is wrong, and that maddr equality does need to be taken into account. After all, if we take port and transport into account, why not maddr? All of this becomes OODLES easier with the new via branch ID. A CANCEL matches an INVITE when they have equal values of the branch ID, and thats it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 03:10:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27476 for ; Thu, 3 Jan 2002 03:10:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA19485 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 03:10:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18697; Thu, 3 Jan 2002 02:58:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA18666 for ; Thu, 3 Jan 2002 02:58:15 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27315 for ; Thu, 3 Jan 2002 02:58:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g037wBVZ006093; Thu, 3 Jan 2002 02:58:11 -0500 (EST) Message-ID: <3C340EF8.4030602@dynamicsoft.com> Date: Thu, 03 Jan 2002 02:57:44 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Terry L Anderson CC: sip@ietf.org Subject: Re: [Sip] Open Issue #342: SDP in 488 References: <3C332D3F.A9A67146@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Terry L Anderson wrote: > Actually I think that this IS in bis-05. 22.41 near the end states: > > "If the warning is caused by the session description, the status > response > SHOULD include a session description similar to that included in OPTIONS > responses..." > Good find. I had missed it. Its clearly in the wrong place... > And 606 (and presumably 488) "...MAY contain a list of reason in a > Warning..." > So I have assumed that the normal response to an INVITE with > unacceptable > payloads would be a 488 or 606 with Warning and therefore SHOULD > contain the > OPTIONS Response-like body. > > If this is not clear in -05, I favor adding more to make it clearly > encouraged. My aim is to try and remove things from the spec, especially things that seem to have never been used. To date, this functionality seems not to have been missed. There is another complication, which is that if we specify that you need to return SDP in a 488/606, and an OPTIONS response, then we need to specify how to format that SDP. That would either be a new spec in mmusic, or more likely, the simcap spec in mmusic. That introduces another dependency, plus its not entirely clear to me yet that simcap is quite on target for this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 03:13:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27512 for ; Thu, 3 Jan 2002 03:13:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA19529 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 03:13:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19257; Thu, 3 Jan 2002 03:03:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19232 for ; Thu, 3 Jan 2002 03:03:56 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27399 for ; Thu, 3 Jan 2002 03:03:54 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g03834VZ006097; Thu, 3 Jan 2002 03:03:05 -0500 (EST) Message-ID: <3C34101D.3010708@dynamicsoft.com> Date: Thu, 03 Jan 2002 03:02:37 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Juha Heinanen CC: Bobby Sardana , Dean Willis , Michael Thomas , John.Hearty@level3.com, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <15410.45087.197490.178067@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > Bobby Sardana writes: > > > Just curious, why can't the 499 be propagated all the way to the UAC > with > > no intermediary (proxy) storage of responses? So if the request > originated > > as UDP and the UAS cannot handle it, because of size limitations, and > > requires that a TCP request be made, just reject the request and > propagate > > it (like some other errors) back to the UAC. The UAC can then > originate a > > TCP request. > > just to ask again, why can't the uas use tcp to send the response even > if it got the request using udp? sip should care what the transport > protocol is. It does care, since it needs to provide its own reliability for the UDP case. Thus, the transaction state machines have timers that are sometimes equal to zero for reliable transports. Sending the response over TCP would therefore: 1. require all client elements to always listen for incoming TCP connections, needless to say that will be fun with nat. 2. make the transaction machines more complicated, since they would need to deal with a possible change in timer values mid-transaction I am all for simple solutions, despite what some people think. However, I am not sure its just as simple as using TCP to send the response. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 03:39:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27128 for ; Thu, 3 Jan 2002 02:45:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA18396 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 02:45:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17579; Thu, 3 Jan 2002 02:25:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17474 for ; Thu, 3 Jan 2002 02:25:22 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26905 for ; Thu, 3 Jan 2002 02:25:21 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g037P1VZ006079; Thu, 3 Jan 2002 02:25:01 -0500 (EST) Message-ID: <3C340731.3040201@dynamicsoft.com> Date: Thu, 03 Jan 2002 02:24:33 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Mark Watson CC: Flemming Andreasen , brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] Open Issue #188: Reply-To References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson wrote: > Jonathan, > > I can't see how the two mechanisms are orthogonal. Reply-To: seems to be > a straight sub-set of the functionality in Remote-Party-ID in > privacy-02. We've been through this one. R-P-ID is a network provided identity. It is not a catch-all for all forms of identification. If that were the case, we would deprecate Contact, From, and To, and use R-P-ID instead. Thus, Reply-To is an end-user provided reply address. > > Anyway, it's your call. If it's closed, it's closed. > > I am a little surprised at the enthusiasm for specific solutions over a > generic one. > > I thought there was considerable value in a generic solution to this > problem which would avoid the need to re-invent the machinery attached > with communicating identity information every time we encounter a new > requirement. In particular the machinery associated with carrying > private information within a trusted domain (although this doesn't apply > to Reply-To). That is only an issue for network inserted information. If I wish to remain private, I would fill out the From and REply-To and New-Fangled-ID header with anonymous values. The issue of general privacy services is that the network needs to authenticate me, and thus insert headers which later need to be removed. Thus, for NETWORK PROVIDED IDENTITY, a general solution is desirable. > > There *is* a difference between defining new individual headers (e.g. > Reply-To) versus defining new types in a more generic header (aka > Remote-Party-ID), and that is that the latter offers some forwards > compatibility advantages - I can be sure that (if RPI is supported) then > the new RPI type header will receive the generic RPI processing even at > nodes which do not support the new type. In contrast, a new header will > just be ignored. See above. It is moot once you realize that R-P-ID is a network provided identity. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 03:41:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27804 for ; Thu, 3 Jan 2002 03:41:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA20438 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 03:41:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19857; Thu, 3 Jan 2002 03:25:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19826 for ; Thu, 3 Jan 2002 03:25:41 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27631 for ; Thu, 3 Jan 2002 03:25:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g038PeVZ006109; Thu, 3 Jan 2002 03:25:40 -0500 (EST) Message-ID: <3C341567.6060303@dynamicsoft.com> Date: Thu, 03 Jan 2002 03:25:11 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Ben Campbell CC: sip@ietf.org Subject: Re: [Sip] Open Issue #290: Registrar increasing registration life time References: <1009565658.1973.7.camel@rocinante> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Actually, I really hate letting a registrar increase the interval, for a > few reasons: > > 1) As you mention, Expires:0 would then require special case processing. > > 2) The registering device should be the "owner" of its registration. It > is the only thing that has any hope to know the lifetime that its > registration is meaningful. If it sends a short Expires header, one must > assume to some degree it knows what it's doing. If it's choice of > Expires violates network _policy_, then a better solution would be to > send some sort of error response, perhaps containing the minimum allowed > expiration. Its interesting to note that this would ALSO require special case handling of expires:0. Really, the problem is not that expiration times are short, the problem is that the client may be trying to refresh too frequently. If the client does not plan to refresh, there is no problem with any duration expiration. Perhaps, then, what is really needed is for a registrar that cares to keep track of the # of registrations over some time period for a particular contact, and if it exceeds a maximum, then generate some kind of error response. > 3) Since there is no way to enforce that a client does not re-register > well before the expiration time, forcing a larger expiration is a fairly > weak solution to registration rate problems. Since older implementations > had a reasonable expectation that the Expires value would not increase, > they may not check for the condition. The ONLY thing solved by the increasing-duration capability was to handle compliant, but "overly zealous" user agents. There is no disagreement that it doesn't help with dos attacks. Perhaps the right solution, then, is to allow registrars to only decrease, and to provide an error response code to provide a general "you're sending too fast, slow down" capability, which would also be helpful for SUBSCRIBE, for example, which will suffer the same problem. Comments? -Jonathan R. > > > On Thu, 2001-12-27 at 11:30, Jonathan Rosenberg wrote: > >>The spec now says that the registrar can increase the registration >>interval. >>This is done to protect the registrar from clients that want to >> > refresh too > >>frequently. However, this introduces interesting complications: >> >> a. it can't really increase Expires: 0, since we do need a way to >>terminate a >>registration, so we would need to special case 0 >> b. the client may choose to register an interval because they want >> > the > >>information to die at a specific time (husband registering his phone >> > at his > >>mistresses number for a brief period, REALLY wants it unregistered >> > when > >>he asks) >> >>So, do we really want to allow the registrar to increase the interval? >> >> >>-Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PH: (973) 952-5000 >>http://www.dynamicsoft.com >> >> >>_______________________________________________ >>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 03:47:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27892 for ; Thu, 3 Jan 2002 03:47:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA20552 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 03:47:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20300; Thu, 3 Jan 2002 03:31:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20271 for ; Thu, 3 Jan 2002 03:31:07 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27683 for ; Thu, 3 Jan 2002 03:31:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g038TcVZ006112; Thu, 3 Jan 2002 03:29:38 -0500 (EST) Message-ID: <3C341655.9030503@dynamicsoft.com> Date: Thu, 03 Jan 2002 03:29:09 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Shail Bhatnagar CC: Brian Stucker , Scott Orton , "'Kiranmai Pavoori'" , vkg , sip Subject: Re: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! References: <3C223DA8.9D5484AE@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Well, if you say there is a real problem I don't want to strand people. I suppose we can attempt to completely deprecate it once we go to draft. So, we will go for the fallback, which is: 1. MUST only send delta times 2. MUST be prepared to handle absolute anyway, to handle older rfc2543, but DONT take that as an excuse to continue using absolute times in bis compliant systems, since its gonna get booted in draft.... -Jonathan R. Shail Bhatnagar wrote: > Jonathan Rosenberg wrote: > >>Let me summarize the results so far. >> >>Scott Orton, Vijay Gurbani, Kiranai Pavoori, Brian Stucker all >> > indicated > >>it was fine to deprecate absolute times (option A). >> >>Brett Tate says they have deployments with registrars that return >>absolute times, but it would be OK to proceed with option A anway; I >>assume this means that the registrars would need to be revved as soon >> > as > >>any of the handsets became bis compliant (since they wouldn't be able >> > to > >>handle the absolute tiems). Note that the opposite is true, you don't >>need to rev the handsets if you upgrade the registrar. >> >>Shail indicated that their registrar uses absolute times. Shail - can >> > we > >>get more details here? Would there be issues in existing deployments >>that would be seriously affected by this change? I'd really like to do >>option A, since otherwise you need to carry around the code for >> > absolute > >>time processing anyway. >> > > Jonathan, Our proxy/registrar generates 200 response of the form > > SIP/2.0 200 OK > Contact: ;expires=gmt stamp > Contact: ;expires=gmt stamp > This is more of an issue for the clients being used > by existing deployments. If customer X, using our > registrar, changes their client and the client cannot > understand this 200 response, there maybe issues. > This gmt time stamp in 200 responses will probably > not be fixed for next few months in our proxy. > > Charles/Sean you want to add something ?? > > Thanks, > Shail > > > > >>Any others? >> >>-Jonathan R. >> >>Brian Stucker wrote: >> >> >>>Propsal A is the way to go. Do away with absolute times, they cause >>> > problems and they're of no real use because all times are relative to > the current clock at the processing node anyhow. > >>>Brian >>> >>>-----Original Message----- >>>From: Orton, Scott [NGC:B633:EXCH] >>>Sent: Tuesday, December 11, 2001 3:46 PM >>>To: 'Kiranmai Pavoori'; jdrosen; vkg >>>Cc: sip >>>Subject: RE: [Sip] Open Issue #178: Deprecate absolute times >>> > absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! > >>> >>> >>>Proposal A is fine. >>> >>>Scott >>>Nortel Networks >>> >>>-----Original Message----- >>>From: Kiranmai Pavoori [ >>> > mailto:kiranmai.pavoori@intervoice-brite.com] > >>>Sent: Tuesday, December 11, 2001 9:48 AM >>>To: jdrosen; vkg >>>Cc: sip >>>Subject: Re: [Sip] Open Issue #178: Deprecate absolute times >>> > absolutely: > >>>SPEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! >>> >>> >>>Proposal A resolves lots of synchronization problems seen in my >>> > work.. > >>> >>> >>> >>>>>>Vijay Gurbani 12/10 12:44 PM >>> >>>>>> >>>Jonathan Rosenberg wrote: >>> >>> >>>>Issue: >>>> >>>>The Expires header and expires param in the Contact header allow for >>>>absolute times expressed in GMT. The problem with using absolute >>>> > times in > >>>>the messages is that they require clock synchronization between the >>>> > two > >>>>elements. >>>> >>>> >>>[...] >>> >>> >>>>PROPOSAL A: >>>> * Remove absolute times entirely from the specification >>>> >>>>PROPOSAL B: >>>> * Elements MUST NOT send messages with absolute times in Expires >>>> > or > >>>>;expires, but they MUST be prepared to receive requests with >>>> > absolute > >>>>times in those headers, for backwards compatibility >>>> >>>>If we can do A, we should. So, speak up NOW if you use absolute >>>> > times!!! > >>>Proposal A is fine. Our registrar sends out delta time in responses >>> > to > >>>Register requests, for instance. >>> >>>Thanks, >>> >>>- vijay >>> >>> >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PH: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 04:11:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28122 for ; Thu, 3 Jan 2002 04:11:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA21300 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 04:11:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20781; Thu, 3 Jan 2002 03:58:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20750 for ; Thu, 3 Jan 2002 03:58:51 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28026 for ; Thu, 3 Jan 2002 03:58:47 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g038FWio011335; Thu, 3 Jan 2002 10:15:32 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15412.4900.592138.81043@harjus.eng.song.fi> Date: Thu, 3 Jan 2002 10:15:32 +0200 To: Bobby Sardana Cc: Jonathan Rosenberg , Dean Willis , Michael Thomas , John.Hearty@level3.com, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations In-Reply-To: <3C3408F8.E2FDDFDF@obsoft.com> References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> <3C3292F8.9090109@dynamicsoft.com> <3C32A234.FA19EF8E@obsoft.com> <15410.45087.197490.178067@harjus.eng.song.fi> <3C3408F8.E2FDDFDF@obsoft.com> X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bobby Sardana writes: > A simple methodology, if TCP/UDP support is needed in SIP, would be: > > a. Use the same transport type for all downstream/upstream communication. > b. When in doubt, use TCP. in a public setup, any sip entity is always in doubt, because it can at any point receive a long message with many record-route headers, for example. it would thus always use tcp, which means that we have no other simple way to solve the problem than to deprecate udp. -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 04:36:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28296 for ; Thu, 3 Jan 2002 04:36:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA22129 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 04:36:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21431; Thu, 3 Jan 2002 04:19:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21401 for ; Thu, 3 Jan 2002 04:19:04 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28159 for ; Thu, 3 Jan 2002 04:18:53 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g039IKK01822; Thu, 3 Jan 2002 10:18:20 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g039IKhO016011; Thu, 3 Jan 2002 11:18:20 +0200 (EET) Message-ID: <3C3421B5.E99C5033@lmf.ericsson.se> Date: Thu, 03 Jan 2002 11:17:41 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Bobby Sardana , Jonathan Rosenberg , Dean Willis , Michael Thomas , John.Hearty@level3.com, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <200112311707.fBVH7gZ09072@valen.greycouncil.com> <3C3292F8.9090109@dynamicsoft.com> <3C32A234.FA19EF8E@obsoft.com> <15410.45087.197490.178067@harjus.eng.song.fi> <3C3408F8.E2FDDFDF@obsoft.com> <15412.4900.592138.81043@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>A simple methodology, if TCP/UDP support is needed in SIP, would be: >> >>a. Use the same transport type for all downstream/upstream communication. >>b. When in doubt, use TCP. > >in a public setup, any sip entity is always in doubt, because it can at >any point receive a long message with many record-route headers, for >example. it would thus always use tcp, which means that we have no >other simple way to solve the problem than to deprecate udp. I do NOT have anything against adding a response code, if such is really needed, telling that the message was too long, and could therefor not be processed. We should, however, remember that there are two cases here: 1. Proxies add headers (R-R ect) to a request. Suddenly the request message becomes too long for the network to handle (using whatever method to find out about that), and the response code is sent back. 2. The request does reach the UAS, but it then finds out that the response message will become too long. For the second case we should also remember that the response message may not become too long when it's sent by the UAS, but later in the network if proxies add headers to the response message (this may happend ie if some kind of header hiding is used). HOWEVER, I think it shall then be an IMPLEMENTATION ISSUE what the receiving node does when it receives that response code. The node MAY choose to use another transport protocol, the node MAY choose to use some compression mechanism, the node MAY choose to shorten the message ie by removing some optional information, the node MAY choose to terminate the call setup. And, in a forking scenario there are many different things the node can do - thing which may be configurable, or chosen using some other kind of policy. And, the action(s) taken most likely also depend on what kind of node (gateway, SIP phone, proxy...) where the response is terminated, so I don't want the spec to say that one always MUST do this and do that... AND, I do NOT support the removal of UDP :) Regards, Christer Holmberg Ericsson Finland > > -- juha > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 04:39:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27809 for ; Thu, 3 Jan 2002 03:41:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA20452 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 03:41:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19677; Thu, 3 Jan 2002 03:16:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19646 for ; Thu, 3 Jan 2002 03:15:58 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27565 for ; Thu, 3 Jan 2002 03:15:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g038FFVZ006105; Thu, 3 Jan 2002 03:15:15 -0500 (EST) Message-ID: <3C3412F8.6080604@dynamicsoft.com> Date: Thu, 03 Jan 2002 03:14:48 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Bobby Sardana CC: Dean Willis , Michael Thomas , John.Hearty@level3.com, jh@lohi.eng.song.fi, sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <3C32A234.FA19EF8E@obsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bobby Sardana wrote: > Greetings all: > > Just curious, why can't the 499 be propagated all the way to the UAC > with > no intermediary (proxy) storage of responses? So if the request > originated > as UDP and the UAS cannot handle it, because of size limitations, and > requires that a TCP request be made, just reject the request and > propagate > it (like some other errors) back to the UAC. The UAC can then originate > a > TCP request. There are many problems with this. One, is that even though the UAC may re-originate with UDP, there is no guarantee that the next hop will do so. Also, the 499 may not actually be propagated back to the UAC in the case of forking; thus, this would add additional cases that trigger the HERFP. I'd rather avoid that. Resubmitting at each hop to the exact same next hop makes things a bit easier. Now, I agree its messy and I would indeed rather have a simpler solution. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 05:57:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28908 for ; Thu, 3 Jan 2002 05:57:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA24215 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 05:57:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23925; Thu, 3 Jan 2002 05:41:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23816 for ; Thu, 3 Jan 2002 05:40:59 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28806 for ; Thu, 3 Jan 2002 05:40:54 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g03AeMa06834; Thu, 3 Jan 2002 05:40:22 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g03Ae6e12785; Thu, 3 Jan 2002 10:40:06 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 10:38:41 -0000 Message-ID: From: "Mark Watson" To: "'Jonathan Rosenberg'" Cc: Flemming Andreasen , brett@broadsoft.com, sip@ietf.org Subject: Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To) Date: Thu, 3 Jan 2002 10:38:34 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19442.CB30CD10" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19442.CB30CD10 Content-Type: text/plain > > Mark Watson wrote: > > > Jonathan, > > > > I can't see how the two mechanisms are orthogonal. > Reply-To: seems to be > > a straight sub-set of the functionality in Remote-Party-ID in > > privacy-02. > > > We've been through this one. R-P-ID is a network provided > identity. It > is not a catch-all for all forms of identification. If that were the > case, we would deprecate Contact, From, and To, and use > R-P-ID instead. > Thus, Reply-To is an end-user provided reply address. > Well, this is what pirvacy-03 says, but not what privacy-02 said. In 02, RPI *was* a generic capability for both network provided & user provided information - that's why it had a tag which indicated whether the information had been verified by the network! Of course we didn't deprecate Contact, From and To - just because we have some pre-existing (& rather fundamental to SIP) specific solutions does not make it bad to add a generic capability later. (BTW, what's with the 'catch-all bad, generic good' language :-) Yes, network provided & user provided identity information have some different characteristics & requirements, but they also have a lot in common - enough that IMO it makes sense to combine the two. Even if the consensus is RPI for network provided, new headers for user provided, then there is still a need for user provided RPI and for RPI tags corresponding to any new identity headers, because there is value in the outbound proxy being able to 'verify' a user provided identity as being valid for that user - ask any CLI-opinionated regulator - in Europe they'd even like us to retro-fit the distinction between verified & unverified identities to analogue CLASS displays on the PSTN, so please lets ensure SIP has full support for this from the beginning. ...Mark ------_=_NextPart_001_01C19442.CB30CD10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To)

 
>
> Mark Watson wrote:
>
> > Jonathan,
> >
> > I can't see how the two mechanisms are = orthogonal.
> Reply-To: seems to be
> > a straight sub-set of the functionality in = Remote-Party-ID in
> > privacy-02.
>
>
> We've been through this one. R-P-ID is a = network provided
> identity. It
> is not a catch-all for all forms of = identification. If that were the
> case, we would deprecate Contact, From, and To, = and use
> R-P-ID instead.
> Thus, Reply-To is an end-user provided reply = address.
>

Well, this is what pirvacy-03 says, but not what = privacy-02 said. In 02, RPI *was* a generic capability for both network = provided & user provided information - that's why it had a tag = which indicated whether the information had been verified by the = network!

Of course we didn't deprecate Contact, From and To - = just because we have some pre-existing (& rather fundamental to = SIP) specific solutions does not make it bad to add a generic = capability later. (BTW, what's with the 'catch-all bad, generic good' = language :-)

Yes, network provided & user provided identity = information have some different characteristics & requirements, but = they also have a lot in common - enough that IMO it makes sense to = combine the two.

Even if the consensus is RPI for network provided, = new headers for user provided, then there is still a need for user = provided RPI and for RPI tags corresponding to any new identity = headers, because there is value in the outbound proxy being able to = 'verify' a user provided identity as being valid for that user - ask = any CLI-opinionated regulator - in Europe they'd even like us to = retro-fit the distinction between verified & unverified identities = to analogue CLASS displays on the PSTN, so please lets ensure SIP has = full support for this from the beginning.

...Mark

------_=_NextPart_001_01C19442.CB30CD10-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 09:00:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01537 for ; Thu, 3 Jan 2002 09:00:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA29536 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 09:00:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29107; Thu, 3 Jan 2002 08:42:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29076 for ; Thu, 3 Jan 2002 08:42:05 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00967 for ; Thu, 3 Jan 2002 08:42:01 -0500 (EST) Received: from metroliner.cs.columbia.edu (IDENT:root@metroliner.cs.columbia.edu [128.59.19.252]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA20494; Thu, 3 Jan 2002 08:42:03 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by metroliner.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id g03Dfqh08511; Thu, 3 Jan 2002 08:42:02 -0500 Message-ID: <3C3460AB.719771F6@cs.columbia.edu> Date: Thu, 03 Jan 2002 08:46:19 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C3300C6.43EFE413@cs.columbia.edu> <3C340A00.2090602@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > Also, it seems odd that if I enter: > > a123 > > this results in one URL (a SIP URL), but if I enter: > > 123 > > this results in a tel URL. The basic problem is that the UA has to guess, in order to be compatible with common usage, what different text strings mean. This is somewhat analogous to the way that web browsers work: typing in "google" in IE will lead to a search site (run by MSN), which will lead to "google.com". Typing "google.de" will lead to a very different site. To me, this is a UI issue - the UA can use heuristics, explicit configuration ("always use tel") or some explicit switch ("check this box to make calls in your home domain"). I don't see why we need to tell UI designers what to do. > > I see it much like what happens when you enter an unqualified domain > name into a local resolver; the remainder of the name is filled in at > the local host with the configured domain. Seems like the same logic > should apply here. And this behavior, as far as I know, isn't standardized anywhere. Some would even argue that default domains have caused a fair amount of grief. (I recall reading as much in some of the recent DNS performance papers.) > > > > > For 911 and 411-style phone numbers, the latter is the only viable > > option until we have a better infrastructure in place. > > For 411, I don't see why its wrong to do sip:411@cs.columbia.edu, which If I'm staying in Houston, 411 in Houston in very different than 411 in New York. I won't be able to get local Texas numbers from my Manhattan directory number. Even worse, calling 511 (repair) in Manhattan when my phone line in Texas isn't working isn't likely to help. > would then realize that its information service and do whats needed. > ARguably, 911 needs to be processed immediately, but I would think that > the right way to do this is for the UA to recognize 911 and use a > special emergency SIP URL that may not be scoped to EITHER > cs.columbia.edu or be a tel URL... but I've not been following the 911 > work too closely so I could be wrong here. The current proposal is that dialing 911 would become sos@home-domain, but be intercepted by the outbound proxy if possible, so it's kind of a hybrid. > > > In any event, UAs > > should probably be prepared to deal with proxies that can't handle tel > > URLs. > > It just seems like another opportunity for interop failures and complexity. Unless you completely rule out tel: URLs in SIP requests, the possibility that your outbound proxy can't handle tel URLs always exists, even if you disallow UI guessing. (Not sure how a protocol spec could do that in any event.) Thus, I think this should be phrased as a wider issue - should we allow tel URLs at all? If not, I can save a lot of effort by just ditching work on 2806bis, since SIP seems to be the major (only?) customer. > > > Currently, our ability to say unambiguously "URL scheme not > > supported" is rather weak. 404 doesn't quite fit. This may suggest > > either a new status code or Warning header value. > > > > The best we can probably do is to allow users to choose and have the UA > > deal with the error case by switching to home resolution. > > I was hoping for one mechanism rather than two... Thus, you're saying no tel URLs at all? _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 09:41:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02354 for ; Thu, 3 Jan 2002 09:41:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA00963 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 09:41:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00278; Thu, 3 Jan 2002 09:29:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00245 for ; Thu, 3 Jan 2002 09:29:39 -0500 (EST) Received: from mail2.vonage.net ([12.144.47.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01951 for ; Thu, 3 Jan 2002 09:29:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [Sip] Open Issue #366: sip v. tel URL MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 3 Jan 2002 09:29:33 -0500 Message-ID: <7CA2FB15D24A30408446333F38607F8C12161B@mail2.vonage.net> Thread-Topic: [Sip] Open Issue #366: sip v. tel URL Thread-Index: AcGTVu61mmcYaM7URFWCmFESF6uEFABC1lFg From: "John Butz" To: "Jonathan Rosenberg" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA00246 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Agreed. Plus consistentcy on the use of a leading '+' for phone numbers listed inside SIP URLs (as specified in E.123 and referred to in E.164)... Last time i checked, E.123 says a leading '+' should be used on business cards and letterhead only. Personally, I'd like to see the '+' dropped and the 'phone number' vs 'string of digits' decision be based on the domain of the UA. I let guys argue the finer points Best regards, --John Butz Vonage T. 732-528-2616 F. 732-287-9119 E. jbutz@vonage.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, January 02, 2002 1:04 AM To: sip@ietf.org Subject: [Sip] Open Issue #366: sip v. tel URL THe spec is silent on what to do when a user enters just a telephone number at a SIP UA. Does the UA generate a SIP URL using the default domain of the UA, or does it generate a tel URL? Do we even need to say anything about this? We might, since otherwise, a UA that always uses tel won't interoperate with a proxy which doesn't support tel at all. I would probably argue that when a user enters an unqualified name to be called, the UA generates a SIP URL, filling in the domain with its domain of administration. This means that no matter what is entered, it is the domain of the UA which is the one that needs to figure out how to interpret it. This makes it work for things beyond phone numbers. Either way, the spec should talk about this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 10:33:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03966 for ; Thu, 3 Jan 2002 10:33:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA03677 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 10:33:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02653; Thu, 3 Jan 2002 10:18:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02617 for ; Thu, 3 Jan 2002 10:18:12 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03729 for ; Thu, 3 Jan 2002 10:18:09 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g03FHcJ10007; Thu, 3 Jan 2002 10:17:42 -0500 (EST) Received: from lucent.com (tla.lra.lucent.com [192.11.62.48]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id KAA07461; Thu, 3 Jan 2002 10:17:37 -0500 (EST) Message-ID: <3C34755C.D6474D27@lucent.com> Date: Thu, 03 Jan 2002 10:14:37 -0500 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #342: SDP in 488 References: <3C332D3F.A9A67146@lucent.com> <3C340EF8.4030602@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------C89B0DDF0FC1B1160C0CEA16" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------C89B0DDF0FC1B1160C0CEA16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Below Jonathan Rosenberg wrote: > Terry L Anderson wrote: > > > Actually I think that this IS in bis-05. 22.41 near the end states: > > > > "If the warning is caused by the session description, the status > > response > > SHOULD include a session description similar to that included in OPTIONS > > responses..." > > > > Good find. I had missed it. Its clearly in the wrong place... > > > And 606 (and presumably 488) "...MAY contain a list of reason in a > > Warning..." > > So I have assumed that the normal response to an INVITE with > > unacceptable > > payloads would be a 488 or 606 with Warning and therefore SHOULD > > contain the > > OPTIONS Response-like body. > > > > If this is not clear in -05, I favor adding more to make it clearly > > encouraged. > > My aim is to try and remove things from the spec, especially things that > seem to have never been used. To date, this functionality seems not to > have been missed. It would be missed if removed. We use it. > There is another complication, which is that if we specify that you need > to return SDP in a 488/606, and an OPTIONS response, then we need to > specify how to format that SDP. That would either be a new spec in > mmusic, or more likely, the simcap spec in mmusic. That introduces > another dependency, plus its not entirely clear to me yet that simcap is > quite on target for this. I thought it was specified, although perhaps you believe it needs more detail. In bis-04 section 8 and the example in 20.8 seemed clear enough to me. Of course much of this is gone in bis-05 (removed along with the reset of the SDP discussion) although the body (and payload list) is still present in the example in 11.2 and 11 suggests codecs as one of the types of things that can be discovered with OPTIONS. I take it you want to remove the body from OPTIONS response as well then and remove the word "codec" from the description in 11. I always felt codec negotiation was the most valuable use of OPTIONS (and 488/606 response). Otherwise finding a common codec is a trial and error process. It is common for gateways to support only symmetric payloads and single audio codec at a time (with telephone-event possibly added). If there is no way to query the other end for a list of supported codecs it is difficult to find one in common. I admit that removing the SDP details from the SIP spec makes this more difficult but I thought that the phrase in bis-04 section 8 (and earlier bis): "The response MAY contain a message body indicating the capabilities of the end system (rather than properties of any existing call)." was clear enough (that any payload list should be all those supported rather than those desired for a single call) and never mentioned SDP. It seems to me that this or some other non-SDP specific description could be sufficient. Of course, it would be nice to have a way to specify restrictions like symmetric codecs required or one codec at a time, etc. but removing even the list makes life even worse. > > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------C89B0DDF0FC1B1160C0CEA16 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard --------------C89B0DDF0FC1B1160C0CEA16-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 10:47:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04337 for ; Thu, 3 Jan 2002 10:47:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04543 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 10:47:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03712; Thu, 3 Jan 2002 10:33:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03667 for ; Thu, 3 Jan 2002 10:33:40 -0500 (EST) Received: from web20303.mail.yahoo.com (web20303.mail.yahoo.com [216.136.226.84]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03962 for ; Thu, 3 Jan 2002 10:33:36 -0500 (EST) Message-ID: <20020103153339.90051.qmail@web20303.mail.yahoo.com> Received: from [12.237.7.244] by web20303.mail.yahoo.com via HTTP; Thu, 03 Jan 2002 07:33:39 PST Date: Thu, 3 Jan 2002 07:33:39 -0800 (PST) From: Jasson Casey Subject: Re: [Sip] Difference in sip bis04/bis05 BNF To: Jonathan Rosenberg Cc: sip@ietf.org In-Reply-To: <3C340345.6090901@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Actually, it just took me a while to dig up the phrase I was looking for. sipbis04 lines 4177-4179: Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon. sipbis05 lines 8235-8238: Even if the "display-name" is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, question mark, or semicolon. I was looking for a clarification in the ambiguity of url-parameters and to/from parameters. As I read from the above statements: whenever (url-parameters | url-headers) are present name-addr will be used, which will wrap the url in "". I was looking for something like this in the BNF. Thanks, Jasson Casey jassoncasey@yahoo.com --- Jonathan Rosenberg wrote: > > > Jasson Casey wrote: > > > I was going through the new BNF and I had a few > > questions. > > > > The first is in sip bis05 line 9830: > > TILDE = LWS " LWS ; tilde > > > > Should the line read: > > TILDE = LWS "~" LWS ; tilde > > > Yes. This is a latex error of some sort. Thanks. > > > > > > The second question is in sip bis05 line 9949: > > headers = "?" header *(" " header) > > > > The corresponding line from bis04 (1107) > > headers = "?" header *("&" header) > > > > Why is the ampersand no longer present? > > > Another latex error. Its correct in the PS/PDF. > > > > > > Finally, I had a question concerning (url|uri) > within > > the to/from headers. Specifically, I am seeking > > clarification on the usage of to/from parameters > (tag, > > name=value, etc). > > > > Originally, I had a concern about the difference > > between a url|uri parameter and a to/from > parameter. > > In bis04 it seemed that the following "<" url|uri > ">" > > *(to/from-params) was used to know the difference. > > Where in bis05 the use seems to be a bit > different: > > > > name-addr = [ display-name ] LAQUOT addr-spec > RAQUOT > > > > So, "<" and ">" are only used for display-name > > applications. > > > What makes you say that? The usage is unchanged. > > > If this is the new usage, then once > > again how do I tell the difference between a > (url|uri) > > parameter and a (to|from) parameter. It seems that > I > > could encounter something like the following: > > > > From: > > > sip:bob@yahoo.com:1234;maddr=224.1.2.3;name=value;tag=1234 > > > > Is name=value a url|uri parameter or a from-param? > > > Nothing has changed. In the above case, maddr, name > and tag would all be > From parameters. Please tell me what text implies > that this has changed. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle > Rock Avenue > Chief Scientist First Floor > dynamicsoft East > Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) > 952-5050 > http://www.jdrosen.net PH: (973) > 952-5000 > http://www.dynamicsoft.com > __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 11:58:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06012 for ; Thu, 3 Jan 2002 11:58:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA09081 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 11:58:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08062; Thu, 3 Jan 2002 11:36:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08030 for ; Thu, 3 Jan 2002 11:36:31 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05607 for ; Thu, 3 Jan 2002 11:36:27 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id QAA09650; Thu, 3 Jan 2002 16:35:40 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id QAA27358; Thu, 3 Jan 2002 16:36:21 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 09:36:17 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B370EC@n0214idc1.oss.level3.com> To: sardana@obsoft.com, jh@lohi.eng.song.fi Cc: jdrosen@dynamicsoft.com, dean.willis@softarmor.com, mat@cisco.com, sip@ietf.org Subject: RE: [Sip] MAJOR Open Issue #184: Message size limitations Date: Thu, 3 Jan 2002 09:36:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Bobby Sardana [mailto:sardana@obsoft.com] > Sent: Thursday, January 03, 2002 12:32 AM > To: Juha Heinanen > Cc: Jonathan Rosenberg; Dean Willis; Michael Thomas; Hearty, John; > sip@ietf.org > Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations > > > From an implementation's perspective, co-orelating responses > from different > transport types can lead to bulky UA implementations. > > A simple methodology, if TCP/UDP support is needed in SIP, would be: > > a. Use the same transport type for all downstream/upstream > communication. I am NOT in favor of this. Some network architectures rely on secure relationships between elements. The transport used up to that point can't override that relationship, i.e. expect UDP to work between two proxies that normally only talk TLS to each other. > b. When in doubt, use TCP. > > If we are planning to mix request/responses using TCP/UDP, > then mandate only one > and deprecate the other. > > Regards, > > Bobby Sardana. > sardana@obsoft.com > > Juha Heinanen wrote: > > > Bobby Sardana writes: > > > > > Just curious, why can't the 499 be propagated all the > way to the UAC with > > > no intermediary (proxy) storage of responses? So if the > request originated > > > as UDP and the UAS cannot handle it, because of size > limitations, and > > > requires that a TCP request be made, just reject the > request and propagate > > > it (like some other errors) back to the UAC. The UAC can > then originate a > > > TCP request. > > > > just to ask again, why can't the uas use tcp to send the > response even > > if it got the request using udp? sip should care what the transport > > protocol is. > > > > -- juha > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 12:09:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06173 for ; Thu, 3 Jan 2002 12:09:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10302 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 12:09:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09131; Thu, 3 Jan 2002 11:58:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09100 for ; Thu, 3 Jan 2002 11:58:34 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06024 for ; Thu, 3 Jan 2002 11:58:29 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g03GvxD18688; Thu, 3 Jan 2002 08:58:00 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP40975; Thu, 3 Jan 2002 08:57:25 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11300; Thu, 3 Jan 2002 08:57:58 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15412.36246.307190.661368@thomasm-u1.cisco.com> Date: Thu, 3 Jan 2002 08:57:58 -0800 (PST) To: Christer Holmberg Cc: Dean Willis , sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations In-Reply-To: <3C33F328.462434B8@lmf.ericsson.se> References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> <3C33009A.6B232FF9@lmf.ericsson.se> <013501c193c7$656d6e50$01000001@dynamicsoft.com> <3C33F328.462434B8@lmf.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg writes: > > Hi, > > The solution to the problem you describe is - SIP. If an operator has > the problem with UDP that you describe, either in the whole of his > network or between specific SIP nodes, he may configure the nodes to use > TCP (or SCTP, or whatever) instead of UDP. Again, that's one of the good > things of having a transport independent protocol. So what happens when the sprawling operations of softarmor.com and mtcc.com need to put their Very Important CEO's in touch? Mike _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 12:45:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06739 for ; Thu, 3 Jan 2002 12:45:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11208 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 12:45:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11044; Thu, 3 Jan 2002 12:34:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11004 for ; Thu, 3 Jan 2002 12:34:15 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06577 for ; Thu, 3 Jan 2002 12:34:11 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g03HWJw18217; Thu, 3 Jan 2002 09:32:36 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP41632; Thu, 3 Jan 2002 09:32:05 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA11304; Thu, 3 Jan 2002 09:32:38 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15412.38326.204066.929296@thomasm-u1.cisco.com> Date: Thu, 3 Jan 2002 09:32:38 -0800 (PST) To: "Mark Watson" Cc: "'Jonathan Rosenberg'" , Flemming Andreasen , brett@broadsoft.com, sip@ietf.org Subject: Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To) In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit For the record, I still don't see any reason why a UAC shouldn't set it. The key property we need to enable is for an interior proxy to either override the value, or create its own value (ie, RPI as known by XXX). The UAC is going to need to assert its identity with strong authentication at some point, so all we're doing here is drawing a distinction between interior proxies and UA's. I don't think this is especially helpful because from the UAS's standpoint they're just going to look at RPI and determine whether they trust who it was signed by. Nor do I see how this can even be enforced. If I can get a message to your UAS either directly or through your upstream proxy, my UAC can set it to whatever it likes. Thus it provides no inherent protection, and to me this just seems like a completely artificial restriction which hinders direct UA-UA interoperability. To your point about unverified/verified: this is easy. At this point, they should all be treated as unverified. Verification *really* requires some sort of cryptographic signed identity which can be checked. The only possible exception would be either direct e2e communication where you have a security association with the peer (and thus know who sent the message), or _just maybe_ if the UAS has an agreement with their upstream proxy that they'll scrub RPI's which come from untrustworthy sources. Allowance for this kind of transitive trust is hazardous though and may, in fact, be an illusion. I'm well acquainted with the tradeoff (public key signatures are expensive), but this entire concept of "trust me because I put in this magic tag" makes me very uneasy. Mike Mark Watson writes: > > We've been through this one. R-P-ID is a network provided > > identity. It > > is not a catch-all for all forms of identification. If that were the > > case, we would deprecate Contact, From, and To, and use > > R-P-ID instead. > > Thus, Reply-To is an end-user provided reply address. > > > > Well, this is what pirvacy-03 says, but not what privacy-02 said. In 02, RPI > *was* a generic capability for both network provided & user provided > information - that's why it had a tag which indicated whether the > information had been verified by the network! > > Of course we didn't deprecate Contact, From and To - just because we have > some pre-existing (& rather fundamental to SIP) specific solutions does not > make it bad to add a generic capability later. (BTW, what's with the > 'catch-all bad, generic good' language :-) > > Yes, network provided & user provided identity information have some > different characteristics & requirements, but they also have a lot in common > - enough that IMO it makes sense to combine the two. > > Even if the consensus is RPI for network provided, new headers for user > provided, then there is still a need for user provided RPI and for RPI tags > corresponding to any new identity headers, because there is value in the > outbound proxy being able to 'verify' a user provided identity as being > valid for that user - ask any CLI-opinionated regulator - in Europe they'd > even like us to retro-fit the distinction between verified & unverified > identities to analogue CLASS displays on the PSTN, so please lets ensure SIP > has full support for this from the beginning. > > ...Mark > > > > > > Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To) > > > >

  >
> >
> Mark Watson wrote: >
> >
> > Jonathan, >
> > >
> > I can't see how the two mechanisms are orthogonal. >
> Reply-To: seems to be >
> > a straight sub-set of the functionality in Remote-Party-ID in >
> > privacy-02. >
> >
> >
> We've been through this one. R-P-ID is a network provided >
> identity. It >
> is not a catch-all for all forms of identification. If that were the >
> case, we would deprecate Contact, From, and To, and use >
> R-P-ID instead. >
> Thus, Reply-To is an end-user provided reply address. >
> >

> >

Well, this is what pirvacy-03 says, but not what privacy-02 said. In 02, RPI *was* a generic capability for both network provided & user provided information - that's why it had a tag which indicated whether the information had been verified by the network!

> >

Of course we didn't deprecate Contact, From and To - just because we have some pre-existing (& rather fundamental to SIP) specific solutions does not make it bad to add a generic capability later. (BTW, what's with the 'catch-all bad, generic good' language :-)

> >

Yes, network provided & user provided identity information have some different characteristics & requirements, but they also have a lot in common - enough that IMO it makes sense to combine the two.

> >

Even if the consensus is RPI for network provided, new headers for user provided, then there is still a need for user provided RPI and for RPI tags corresponding to any new identity headers, because there is value in the outbound proxy being able to 'verify' a user provided identity as being valid for that user - ask any CLI-opinionated regulator - in Europe they'd even like us to retro-fit the distinction between verified & unverified identities to analogue CLASS displays on the PSTN, so please lets ensure SIP has full support for this from the beginning.

> >

...Mark >

> > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 13:03:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07244 for ; Thu, 3 Jan 2002 13:03:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12415 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 13:04:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11590; Thu, 3 Jan 2002 12:55:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11562 for ; Thu, 3 Jan 2002 12:55:32 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06977 for ; Thu, 3 Jan 2002 12:55:29 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g03HsUq00010; Thu, 3 Jan 2002 09:54:30 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP42151; Thu, 3 Jan 2002 09:53:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA11307; Thu, 3 Jan 2002 09:54:28 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15412.39636.325137.103075@thomasm-u1.cisco.com> Date: Thu, 3 Jan 2002 09:54:28 -0800 (PST) To: Henning Schulzrinne Cc: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL In-Reply-To: <3C3460AB.719771F6@cs.columbia.edu> References: <3C3300C6.43EFE413@cs.columbia.edu> <3C340A00.2090602@dynamicsoft.com> <3C3460AB.719771F6@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I find Henning's arguments pretty persuasive, but one side nit bothers me: Henning Schulzrinne writes: > The current proposal is that dialing 911 would become sos@home-domain, > but be intercepted by the outbound proxy if possible, so it's kind of a > hybrid. My outbound proxy may never move, so this is not in any way generalizable. I understand that some people want to deploy proxies that way, but I strenuously object to this hack being the mechanism by which we localize 911. Mike _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 13:04:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07280 for ; Thu, 3 Jan 2002 13:04:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12439 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 13:04:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11537; Thu, 3 Jan 2002 12:54:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11508 for ; Thu, 3 Jan 2002 12:54:02 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06941 for ; Thu, 3 Jan 2002 12:53:59 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id RAA06045; Thu, 3 Jan 2002 17:50:53 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id RAA15576; Thu, 3 Jan 2002 17:53:53 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 10:53:49 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B370ED@n0214idc1.oss.level3.com> To: jdrosen@dynamicsoft.com, dean.willis@softarmor.com Cc: mat@cisco.com, jh@lohi.eng.song.fi, sip@ietf.org Subject: RE: [Sip] MAJOR Open Issue #184: Message size limitations Date: Thu, 3 Jan 2002 10:53:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Comments inline. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, January 01, 2002 9:56 PM > To: Dean Willis > Cc: Michael Thomas; Hearty, John; jh@lohi.eng.song.fi; sip@ietf.org > Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations > > > > > Dean Willis wrote: > > > eh, the smallest v4 MTU implementation I've seen was 576 . > . . which > > was common on old PPP and SLIP implementations. But even > so, it can be > > challenging to fit into 576 . . . > > > I don't think we need to worry about 576. It seems to be OK > to take the > ethernet MTU and subtract away the various overheads. I seem > to recall > that we did this for IM and arrived at 1280. > > Anyway, the interesting question here is handling the case where the > request whent UDP and the response should go TCP since its above the > path MTU. This can get a bit complicated. > > One of the complications is that proxies are transactional > entities. So, > if we take the approach that "when a server has a response > that is too > large to send, it returns a specific error response telling > the client > to try tcp", this means that the actual response is > effectively dropped > on the floor. When the new request arrives over TCP, it will create a > new transaction and new processing at the proxy, there is no > easy way to > correlate them, or for the proxy to know that it needs to now > send that > previous response. We could try to do that (after all, we can > correlate > CANCEL to INVITE transactions), but its a larger change. > > Without the ability to correlate the transactions, I think I > can prove > that through an N proxy chain, it will reuqire O(N^2) messages to get > the final response when this truncation happens. Heres why. > Consider the > UAC that is connected to proxy P1, which goes to P2, etc., to > PN, to the > UAS. The original request goes all UDP. The UAS can't send > its response > over UDP, so its sends the error (say 499 for now). The 499 > goes to PN, > which now retries over TCP. The response gets to PN, but PN can't > forward it to PN-1. So, PN returns 499. PN-1 retries over > TCP. This is a > new transaction, so PN forwards to the UAS (presumably over TCP this > time, otherwise we get an INFINITE ping-pong effect!), which > responds. > Now, that response goes to PN, to PN-1, which now can't send > it to PN-2, > so it returns 499. PN-2 retries, and now that request goes > all the way > to the UAS once more..... and there you have O(N^2). I'll continue to use the 499 example response for now. There is an assumption above that the proxy receiving the 499 is trying to fix the problem with a new transaction on a different transport. That assumption is what is leading to this messy transaction correlation requirement. I propose the 499 simply be proxied back to the UAC in any case. The response would then mean that some where along the route to the UAS the message got too large for the transport to carry. The session wouldn't succeed, but keeping it simple is better than introducing a bunch of ugly requirements to try and make the session work. There could be a MAY in the spec for the UAC to retry with a trimmed down request. If enough users in a network complain about the problem, the proxy owner causing the 499s could consider changing their default transport. There is the possibility this could happen during an established dialog, and provisions for falling back to the last state would be needed in the spec, if something does not already exist. The possibility of a response somehow becomming too large to forward is one thing that is a problem with this approach. This would not typically happen, since responses normally get smaller heading towards the UAC. However, if for example as Christer suggests some kind of header hiding is done, this could happen, and a 2xx response for example from the UAS could be turned into a 499. Not sure what would be an appropriate way of dealing with this, perhaps just let the 2xx time out. > > So, I have convinced myself that truncated responses won't > work unless > there is a way for a proxy to correlate a new transaction with the > previous, such that it knows it needs to send the final response it > meant to send on the previous, but couldn't. > > I suppose we could simply include the original transaction ID > in the new > request, in some header somewhere. The change to bis of using formal > transaction IDs in the via branch param makes that feasible. > I need to > think about if there are any lurking demons with that approach.... > > Thanks, > Jonathan R. > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 13:10:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07401 for ; Thu, 3 Jan 2002 13:10:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12507 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 13:10:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11965; Thu, 3 Jan 2002 12:59:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11934 for ; Thu, 3 Jan 2002 12:59:31 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07106 for ; Thu, 3 Jan 2002 12:59:29 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA05141; Thu, 3 Jan 2002 12:59:27 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g03HxMJ1019677; Thu, 3 Jan 2002 12:59:22 -0500 (EST) Message-ID: <3C349BF9.AC0FB3D5@cs.columbia.edu> Date: Thu, 03 Jan 2002 12:59:21 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C3300C6.43EFE413@cs.columbia.edu> <3C340A00.2090602@dynamicsoft.com> <3C3460AB.719771F6@cs.columbia.edu> <15412.39636.325137.103075@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > I find Henning's arguments pretty persuasive, > but one side nit bothers me: > > Henning Schulzrinne writes: > > The current proposal is that dialing 911 would become sos@home-domain, > > but be intercepted by the outbound proxy if possible, so it's kind of a > > hybrid. > > My outbound proxy may never move, so this is > not in any way generalizable. I understand that > some people want to deploy proxies that way, > but I strenuously object to this hack being the > mechanism by which we localize 911. I wouldn't, either. However, I'm trying to find heuristics that are more likely to work in the short term. I've made proposals (and will spell them out in more detail soon) on how to make it possible for any entity to locate the appropriate PSAP. However, this requires a database that somebody needs to build and maintain. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 13:44:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07927 for ; Thu, 3 Jan 2002 13:44:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13642 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 13:44:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12775; Thu, 3 Jan 2002 13:17:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12668 for ; Thu, 3 Jan 2002 13:17:45 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07524 for ; Thu, 3 Jan 2002 13:17:42 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g03IHBo04786; Thu, 3 Jan 2002 13:17:11 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g03IGv517983; Thu, 3 Jan 2002 18:16:57 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jan 2002 18:15:32 -0000 Message-ID: From: "Mark Watson" To: "'Michael Thomas'" Cc: "'Jonathan Rosenberg'" , Flemming Andreasen , brett@broadsoft.com, sip@ietf.org Subject: RE: Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To) Date: Thu, 3 Jan 2002 18:15:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19482.A03DD270" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19482.A03DD270 Content-Type: text/plain Michael, The point is that there are, and will continue to be, service deployment models where the user has a Service Level Agreement with a local service provider, and this service provider has SLAs with other service providers etc. etc., and these SLAs can include a committment that identity information is either verified or marked as unverified by the sender. Yes, this is 'transitive trust', yes, cryptographic solutions are an alternative but there are pros and cons. Also, such SLAs are already familiar to many existing Service providers. It's not 'trust me because I put in a magic tag', but 'trust me because you have a binding Service Level Agreement which says I am trustworthy'. It's not the only deployment model & it certainly has disadvantages, but it's not one we can ignore, especially in the short/medium term. ...Mark -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: 03 January 2002 17:33 To: Watson, Mark [MDN05:EP10:EXCH] Cc: 'Jonathan Rosenberg'; Flemming Andreasen; brett@broadsoft.com; sip@ietf.org Subject: Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To) For the record, I still don't see any reason why a UAC shouldn't set it. The key property we need to enable is for an interior proxy to either override the value, or create its own value (ie, RPI as known by XXX). The UAC is going to need to assert its identity with strong authentication at some point, so all we're doing here is drawing a distinction between interior proxies and UA's. I don't think this is especially helpful because from the UAS's standpoint they're just going to look at RPI and determine whether they trust who it was signed by. Nor do I see how this can even be enforced. If I can get a message to your UAS either directly or through your upstream proxy, my UAC can set it to whatever it likes. Thus it provides no inherent protection, and to me this just seems like a completely artificial restriction which hinders direct UA-UA interoperability. To your point about unverified/verified: this is easy. At this point, they should all be treated as unverified. Verification *really* requires some sort of cryptographic signed identity which can be checked. The only possible exception would be either direct e2e communication where you have a security association with the peer (and thus know who sent the message), or _just maybe_ if the UAS has an agreement with their upstream proxy that they'll scrub RPI's which come from untrustworthy sources. Allowance for this kind of transitive trust is hazardous though and may, in fact, be an illusion. I'm well acquainted with the tradeoff (public key signatures are expensive), but this entire concept of "trust me because I put in this magic tag" makes me very uneasy. Mike Mark Watson writes: > > We've been through this one. R-P-ID is a network provided > > identity. It > > is not a catch-all for all forms of identification. If that were the > > case, we would deprecate Contact, From, and To, and use > > R-P-ID instead. > > Thus, Reply-To is an end-user provided reply address. > > > > Well, this is what pirvacy-03 says, but not what privacy-02 said. In 02, RPI > *was* a generic capability for both network provided & user provided > information - that's why it had a tag which indicated whether the > information had been verified by the network! > > Of course we didn't deprecate Contact, From and To - just because we have > some pre-existing (& rather fundamental to SIP) specific solutions does not > make it bad to add a generic capability later. (BTW, what's with the > 'catch-all bad, generic good' language :-) > > Yes, network provided & user provided identity information have some > different characteristics & requirements, but they also have a lot in common > - enough that IMO it makes sense to combine the two. > > Even if the consensus is RPI for network provided, new headers for user > provided, then there is still a need for user provided RPI and for RPI tags > corresponding to any new identity headers, because there is value in the > outbound proxy being able to 'verify' a user provided identity as being > valid for that user - ask any CLI-opinionated regulator - in Europe they'd > even like us to retro-fit the distinction between verified & unverified > identities to analogue CLASS displays on the PSTN, so please lets ensure SIP > has full support for this from the beginning. > > ...Mark > > > > > > Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To) > > > >

  >
> >
> Mark Watson wrote: >
> >
> > Jonathan, >
> > >
> > I can't see how the two mechanisms are orthogonal. >
> Reply-To: seems to be >
> > a straight sub-set of the functionality in Remote-Party-ID in >
> > privacy-02. >
> >
> >
> We've been through this one. R-P-ID is a network provided >
> identity. It >
> is not a catch-all for all forms of identification. If that were the >
> case, we would deprecate Contact, From, and To, and use >
> R-P-ID instead. >
> Thus, Reply-To is an end-user provided reply address. >
> >

> >

Well, this is what pirvacy-03 says, but not what privacy-02 said. In 02, RPI *was* a generic capability for both network provided & user provided information - that's why it had a tag which indicated whether the information had been verified by the network!

> >

Of course we didn't deprecate Contact, From and To - just because we have some pre-existing (& rather fundamental to SIP) specific solutions does not make it bad to add a generic capability later. (BTW, what's with the 'catch-all bad, generic good' language :-)

> >

Yes, network provided & user provided identity information have some different characteristics & requirements, but they also have a lot in common - enough that IMO it makes sense to combine the two.

> >

Even if the consensus is RPI for network provided, new headers for user provided, then there is still a need for user provided RPI and for RPI tags corresponding to any new identity headers, because there is value in the outbound proxy being able to 'verify' a user provided identity as being valid for that user - ask any CLI-opinionated regulator - in Europe they'd even like us to retro-fit the distinction between verified & unverified identities to analogue CLASS displays on the PSTN, so please lets ensure SIP has full support for this from the beginning.

> >

...Mark >

> > > ------_=_NextPart_001_01C19482.A03DD270 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Privacy draft (was: RE: [Sip] Open Issue #188: = Reply-To)

Michael,

The point is that there are, and will continue to be, = service deployment models where the user has a Service Level Agreement = with a local service provider, and this service provider has SLAs with = other service providers etc. etc., and these SLAs can include a = committment that identity information is either verified or marked as = unverified by the sender.

Yes, this is 'transitive trust', yes, cryptographic = solutions are an alternative but there are pros and cons. Also, such = SLAs are already familiar to many existing Service = providers.

It's not 'trust me because I put in a magic tag', but = 'trust me because you have a binding Service Level Agreement which says = I am trustworthy'.

It's not the only deployment model & it certainly = has disadvantages, but it's not one we can ignore, especially in the = short/medium term.

...Mark



-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: 03 January 2002 17:33
To: Watson, Mark [MDN05:EP10:EXCH]
Cc: 'Jonathan Rosenberg'; Flemming Andreasen; = brett@broadsoft.com;
sip@ietf.org
Subject: Privacy draft (was: RE: [Sip] Open Issue = #188: Reply-To)



For the record, I still don't see any reason why = a
UAC shouldn't set it. The key property we need = to
enable is for an interior proxy to either = override
the value, or create its own value (ie, RPI = as
known by XXX). The UAC is going to need to = assert
its identity with strong authentication at = some
point, so all we're doing here is drawing a
distinction between interior proxies and UA's. = I
don't think this is especially helpful = because
from the UAS's standpoint they're just going = to
look at RPI and determine whether they trust = who
it was signed by. Nor do I see how this can = even
be enforced. If I can get a message to your = UAS
either directly or through your upstream proxy, = my
UAC can set it to whatever it likes. Thus it
provides no inherent protection, and to me = this
just seems like a completely artificial
restriction which hinders direct UA-UA
interoperability.

To your point about unverified/verified: this = is
easy. At this point, they should all be treated = as
unverified. Verification *really* requires = some
sort of cryptographic signed identity which can = be
checked. The only possible exception would be
either direct e2e communication where you have = a
security association with the peer (and thus = know
who sent the message), or _just maybe_ if the = UAS
has an agreement with their upstream proxy that
they'll scrub RPI's which come from = untrustworthy
sources. Allowance for this kind of = transitive
trust is hazardous though and may, in fact, be = an
illusion. I'm well acquainted with the = tradeoff
(public key signatures are expensive), but = this
entire concept of "trust me because I put in = this
magic tag" makes me very uneasy.

         = Mike

Mark Watson writes:
 > > We've been through this one. R-P-ID = is a network provided
 > > identity. It
 > > is not a catch-all for all forms of = identification. If that were the
 > > case, we would deprecate Contact, = From, and To, and use
 > > R-P-ID instead.
 > > Thus, Reply-To is an end-user = provided reply address.
 > >
 >
 > Well, this is what pirvacy-03 says, but = not what privacy-02 said. In 02, RPI
 > *was* a generic capability for both = network provided & user provided
 > information - that's why it had a tag = which indicated whether the
 > information had been verified by the = network!
 >
 > Of course we didn't deprecate Contact, = From and To - just because we have
 > some pre-existing (& rather = fundamental to SIP) specific solutions does not
 > make it bad to add a generic capability = later. (BTW, what's with the
 > 'catch-all bad, generic good' language = :-)
 >
 > Yes, network provided & user provided = identity information have some
 > different characteristics & = requirements, but they also have a lot in common
 > - enough that IMO it makes sense to = combine the two.
 >
 > Even if the consensus is RPI for network = provided, new headers for user
 > provided, then there is still a need for = user provided RPI and for RPI tags
 > corresponding to any new identity = headers, because there is value in the
 > outbound proxy being able to 'verify' a = user provided identity as being
 > valid for that user - ask any = CLI-opinionated regulator - in Europe they'd
 > even like us to retro-fit the distinction = between verified & unverified
 > identities to analogue CLASS displays on = the PSTN, so please lets ensure SIP
 > has full support for this from the = beginning.
 >
 > ...Mark
 > <!DOCTYPE HTML PUBLIC = "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii">
 > <META NAME=3D"Generator" = CONTENT=3D"MS Exchange Server version 5.5.2654.89">
 > <TITLE>Privacy draft (was: RE: = [Sip] Open Issue #188: Reply-To)</TITLE>
 > </HEAD>
 > <BODY>
 >
 > <P><FONT = SIZE=3D2>&nbsp;</FONT>
 > <BR><FONT SIZE=3D2>&gt; = </FONT>
 > <BR><FONT SIZE=3D2>&gt; = Mark Watson wrote:</FONT>
 > <BR><FONT SIZE=3D2>&gt; = </FONT>
 > <BR><FONT SIZE=3D2>&gt; = &gt; Jonathan, </FONT>
 > <BR><FONT SIZE=3D2>&gt; = &gt; </FONT>
 > <BR><FONT SIZE=3D2>&gt; = &gt; I can't see how the two mechanisms are orthogonal. = </FONT>
 > <BR><FONT SIZE=3D2>&gt; = Reply-To: seems to be</FONT>
 > <BR><FONT SIZE=3D2>&gt; = &gt; a straight sub-set of the functionality in Remote-Party-ID = in</FONT>
 > <BR><FONT SIZE=3D2>&gt; = &gt; privacy-02.</FONT>
 > <BR><FONT SIZE=3D2>&gt; = </FONT>
 > <BR><FONT SIZE=3D2>&gt; = </FONT>
 > <BR><FONT SIZE=3D2>&gt; = We've been through this one. R-P-ID is a network provided = </FONT>
 > <BR><FONT SIZE=3D2>&gt; = identity. It </FONT>
 > <BR><FONT SIZE=3D2>&gt; = is not a catch-all for all forms of identification. If that were the = </FONT>
 > <BR><FONT SIZE=3D2>&gt; = case, we would deprecate Contact, From, and To, and use = </FONT>
 > <BR><FONT SIZE=3D2>&gt; = R-P-ID instead. </FONT>
 > <BR><FONT SIZE=3D2>&gt; = Thus, Reply-To is an end-user provided reply = address.</FONT>
 > <BR><FONT SIZE=3D2>&gt; = </FONT>
 > </P>
 >
 > <P><FONT SIZE=3D2>Well, this = is what pirvacy-03 says, but not what privacy-02 said. In 02, RPI *was* = a generic capability for both network provided &amp; user provided = information - that's why it had a tag which indicated whether the = information had been verified by the = network!</FONT></P>

 >
 > <P><FONT SIZE=3D2>Of course = we didn't deprecate Contact, From and To - just because we have some = pre-existing (&amp; rather fundamental to SIP) specific solutions = does not make it bad to add a generic capability later. (BTW, what's = with the 'catch-all bad, generic good' language = :-)</FONT></P>

 >
 > <P><FONT SIZE=3D2>Yes, = network provided &amp; user provided identity information have some = different characteristics &amp; requirements, but they also have a = lot in common - enough that IMO it makes sense to combine the = two.</FONT></P>

 >
 > <P><FONT SIZE=3D2>Even if the = consensus is RPI for network provided, new headers for user provided, = then there is still a need for user provided RPI and for RPI tags = corresponding to any new identity headers, because there is value in = the outbound proxy being able to 'verify' a user provided identity as = being valid for that user - ask any CLI-opinionated regulator - in = Europe they'd even like us to retro-fit the distinction between = verified &amp; unverified identities to analogue CLASS displays on = the PSTN, so please lets ensure SIP has full support for this from the = beginning.</FONT></P>

 >
 > <P><FONT = SIZE=3D2>...Mark</FONT>
 > </P>
 >
 > </BODY>
 > </HTML>

------_=_NextPart_001_01C19482.A03DD270-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 14:43:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09414 for ; Thu, 3 Jan 2002 14:43:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16340 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 14:43:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15210; Thu, 3 Jan 2002 14:23:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15176 for ; Thu, 3 Jan 2002 14:23:39 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08805 for ; Thu, 3 Jan 2002 14:23:21 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g03JMcD19797; Thu, 3 Jan 2002 11:22:38 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP44642; Thu, 3 Jan 2002 11:22:04 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA11311; Thu, 3 Jan 2002 11:22:37 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15412.44924.974380.301716@thomasm-u1.cisco.com> Date: Thu, 3 Jan 2002 11:22:36 -0800 (PST) To: "Mark Watson" Cc: "'Michael Thomas'" , "'Jonathan Rosenberg'" , Flemming Andreasen , brett@broadsoft.com, sip@ietf.org Subject: RE: Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To) In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mark Watson writes: > Michael, > > The point is that there are, and will continue to be, service deployment > models where the user has a Service Level Agreement with a local service > provider, and this service provider has SLAs with other service providers > etc. etc., and these SLAs can include a committment that identity > information is either verified or marked as unverified by the sender. The issue here is not whether a particular business model is good or bad, but whether the protocol should assert whether something is verified or not, and expect something on the far end to take action based on that tag. Without crypographic identity verification, the tag is somewhere between impotent and highly misleading. I find that pretty problematic. If service providers want to structure the _contents_ of the RPI based on handshakes, they're completely at liberty since SIP doesn't have to say anything about that. Once you involve the protocol itself, we should be a lot more circumspect. Mike _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 14:55:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09782 for ; Thu, 3 Jan 2002 14:55:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17219 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 14:55:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16184; Thu, 3 Jan 2002 14:40:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16154 for ; Thu, 3 Jan 2002 14:40:19 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09300 for ; Thu, 3 Jan 2002 14:40:15 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g03JeDVZ006358; Thu, 3 Jan 2002 14:40:14 -0500 (EST) Message-ID: <3C34B381.5020005@dynamicsoft.com> Date: Thu, 03 Jan 2002 14:39:45 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jasson Casey CC: sip@ietf.org Subject: Re: [Sip] Difference in sip bis04/bis05 BNF References: <20020103153339.90051.qmail@web20303.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jasson Casey wrote: > Actually, it just took me a while to dig up the phrase > I was looking for. > > sipbis04 lines 4177-4179: > > Even if the "display-name" is empty, the "name-addr" > form MUST be used if the "addr-spec" contains a comma, > question mark, or semicolon. > > sipbis05 lines 8235-8238: > > Even if the "display-name" is empty, the "name-addr" > form MUST be used if the "addr-spec" contains a comma, > question mark, or semicolon. > > I was looking for a clarification in the ambiguity of > url-parameters and to/from parameters. As I read from > the above statements: whenever (url-parameters | > url-headers) are present name-addr will be used, which > will wrap the url in "". I was looking for > something like this in the BNF. Its in the BNF, since the name-addr mandates the angle brackets. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 15:03:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09975 for ; Thu, 3 Jan 2002 15:03:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA17746 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 15:03:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17049; Thu, 3 Jan 2002 14:53:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16834 for ; Thu, 3 Jan 2002 14:52:54 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09719 for ; Thu, 3 Jan 2002 14:52:50 -0500 (EST) Received: from cisco.com (sjc-vpn2-602.cisco.com [10.21.114.90]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA08431; Thu, 3 Jan 2002 11:51:58 -0800 (PST) Message-ID: <3C34B67E.A5D7A7F8@cisco.com> Date: Thu, 03 Jan 2002 14:52:30 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Mark Watson , "'Jonathan Rosenberg'" , brett@broadsoft.com, sip@ietf.org Subject: Re: Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To) References: <15412.44924.974380.301716@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Mark Watson writes: > > Michael, > > > > The point is that there are, and will continue to be, service deployment > > models where the user has a Service Level Agreement with a local service > > provider, and this service provider has SLAs with other service providers > > etc. etc., and these SLAs can include a committment that identity > > information is either verified or marked as unverified by the sender. > > The issue here is not whether a particular > business model is good or bad, but whether the > protocol should assert whether something is > verified or not, and expect something on the far > end to take action based on that tag. It doesn't expect the far end to do anything - it merely asserts that is has been verified. Whether the far-end chooses to trust that or not is up to it. > Without > crypographic identity verification, the tag is > somewhere between impotent and highly misleading. Deja vu. Yes, the transtive trust model is weak and that is pointed out in the privacy draft. Yes, cryptography based authentication is much better, but we just don't have the required PKI infrastructure to support this in place, nor is everybody willing to pay the price for it. We've had this discussion numerous times, and as far as I know nothing has changed. -- Flemming > > I find that pretty problematic. If service > providers want to structure the _contents_ of the > RPI based on handshakes, they're completely at > liberty since SIP doesn't have to say anything > about that. Once you involve the protocol itself, > we should be a lot more circumspect. > > Mike -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 15:15:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10194 for ; Thu, 3 Jan 2002 15:15:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18116 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 15:15:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17301; Thu, 3 Jan 2002 14:58:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17270 for ; Thu, 3 Jan 2002 14:58:03 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09816 for ; Thu, 3 Jan 2002 14:57:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g03JvSVZ006371; Thu, 3 Jan 2002 14:57:29 -0500 (EST) Message-ID: <3C34B78C.2090004@dynamicsoft.com> Date: Thu, 03 Jan 2002 14:57:00 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C3460AB.719771F6@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > The basic problem is that the UA has to guess, in order to be compatible > with common usage, what different text strings mean. This is somewhat > analogous to the way that web browsers work: typing in "google" in IE > will lead to a search site (run by MSN), which will lead to > "google.com". Typing "google.de" will lead to a very different site. > > To me, this is a UI issue - the UA can use heuristics, explicit > configuration ("always use tel") or some explicit switch ("check this > box to make calls in your home domain"). I don't see why we need to tell > UI designers what to do. True, it is always possible for UI to allow the user to be explicit about tel URL. > > >>I see it much like what happens when you enter an unqualified domain >>name into a local resolver; the remainder of the name is filled in at >>the local host with the configured domain. Seems like the same logic >>should apply here. >> > > And this behavior, as far as I know, isn't standardized anywhere. Some > would even argue that default domains have caused a fair amount of > grief. (I recall reading as much in some of the recent DNS performance > papers.) Do you remember what the specific problem is? > > >>>For 911 and 411-style phone numbers, the latter is the only viable >>>option until we have a better infrastructure in place. >>> >>For 411, I don't see why its wrong to do sip:411@cs.columbia.edu, >> > which > > If I'm staying in Houston, 411 in Houston in very different than 411 in > New York. I won't be able to get local Texas numbers from my Manhattan > directory number. Even worse, calling 511 (repair) in Manhattan when my > phone line in Texas isn't working isn't likely to help. Good point. >>>In any event, UAs >>>should probably be prepared to deal with proxies that can't handle >>> > tel > >>>URLs. >>> >>It just seems like another opportunity for interop failures and >> > complexity. > > Unless you completely rule out tel: URLs in SIP requests, the > possibility that your outbound proxy can't handle tel URLs always > exists, even if you disallow UI guessing. (Not sure how a protocol spec > could do that in any event.) > > Thus, I think this should be phrased as a wider issue - should we allow > tel URLs at all? If not, I can save a lot of effort by just ditching > work on 2806bis, since SIP seems to be the major (only?) customer. No, I don't want to ditch them. I am just searching for the right things to say in the spec to avoid interop issues. For example, if I enter in 123 into my sip phone (targeted for extension 123 in my domain), and the phone sends out tel:123, and my home proxy thinks its a pstn number, and thus sends it to a gateway, which fails since its not a PSTN number, thats bad. Now, what element has done the wrong thing here? Did the UA do the wrong thing by using a tel URL? Did the proxy do the wrong thing by interpreting the tel URL as a PSTN number? Looking at either element individually, it doesn't seem like either did the wrong thing, which would lead me to believe that the spec has to say something here so it doesn't happen. The issue is similar with inclusion or not of the + sign. These COULD be configured, but it seems like an undue configuration burden... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 15:26:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10441 for ; Thu, 3 Jan 2002 15:26:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18372 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 15:26:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18059; Thu, 3 Jan 2002 15:12:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18030 for ; Thu, 3 Jan 2002 15:12:49 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10147 for ; Thu, 3 Jan 2002 15:12:44 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA14596; Thu, 3 Jan 2002 15:12:45 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g03KCeJ1023379; Thu, 3 Jan 2002 15:12:40 -0500 (EST) Message-ID: <3C34BB38.4CADE13@cs.columbia.edu> Date: Thu, 03 Jan 2002 15:12:40 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C3460AB.719771F6@cs.columbia.edu> <3C34B78C.2090004@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > And this behavior, as far as I know, isn't standardized anywhere. Some > > would even argue that default domains have caused a fair amount of > > grief. (I recall reading as much in some of the recent DNS performance > > papers.) > > Do you remember what the specific problem is? http://cider.caida.org/~evi/sigcomm/paper.html "This last example is typical of a bug in the DNS data files at the local site. If a name that should end in a dot and therefore be absolute has no dot, the local nameserver will add the local domain to complete the name. A bug in at least one nameserver implementation adds the local domain recursively until it is 256 characters long (the limit). The WSCOOPER example has been truncated to fit the page!" I'm not arguing that this is a big deal, particularly since for SIP URLs, it's easier to tell if you need to add the domain or not. > No, I don't want to ditch them. I am just searching for the right things > to say in the spec to avoid interop issues. > > For example, if I enter in 123 into my sip phone (targeted for extension > 123 in my domain), and the phone sends out tel:123, and my home proxy > thinks its a pstn number, and thus sends it to a gateway, which fails > since its not a PSTN number, thats bad. Now, what element has done the > wrong thing here? Did the UA do the wrong thing by using a tel URL? Did > the proxy do the wrong thing by interpreting the tel URL as a PSTN > number? Looking at either element individually, it doesn't seem like > either did the wrong thing, which would lead me to believe that the spec > has to say something here so it doesn't happen. I just don't see how we can mandate the translation of user input into protocol elements. If anything, this belongs in more informal documents such as "Suggestions for IP phones" that Henry Sinnreich and others are putting together. I'm not aware of any equivalent description for, say, email addresses (what happens if I type "postmaster" - in my particular UI case, it checks whether there is a match in the address book by nickname and fills in the rest. Not always appropriate, needless to say, but I can't think of a better heuristic beyond requiring a "did I guess right" confirmation user interface.) I'm not sure how cell phones handle this - if my cell home area code is 201, but I'm roaming in 415, and then type a 7-digit number, will it be treated as a 201 number or a 415 number? > > The issue is similar with inclusion or not of the + sign. > > These COULD be configured, but it seems like an undue configuration > burden... I agree, but don't see a good solution that doesn't rule out valid UA behavior. Unfortunately, this is hardly the only item that needs to be configured, hopefully automatically. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 15:27:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAB10494 for ; Thu, 3 Jan 2002 15:27:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18391 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 15:27:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17959; Thu, 3 Jan 2002 15:11:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17933 for ; Thu, 3 Jan 2002 15:11:02 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10088 for ; Thu, 3 Jan 2002 15:10:58 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g03KA9w04380; Thu, 3 Jan 2002 12:10:09 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP45994; Thu, 3 Jan 2002 12:09:56 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA11330; Thu, 3 Jan 2002 12:10:29 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15412.47796.886573.183390@thomasm-u1.cisco.com> Date: Thu, 3 Jan 2002 12:10:28 -0800 (PST) To: Flemming Andreasen Cc: Michael Thomas , Mark Watson , "'Jonathan Rosenberg'" , brett@broadsoft.com, sip@ietf.org Subject: Re: Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To) In-Reply-To: <3C34B67E.A5D7A7F8@cisco.com> References: <15412.44924.974380.301716@thomasm-u1.cisco.com> <3C34B67E.A5D7A7F8@cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen writes: > > The issue here is not whether a particular > > business model is good or bad, but whether the > > protocol should assert whether something is > > verified or not, and expect something on the far > > end to take action based on that tag. > > It doesn't expect the far end to do anything - it merely asserts that is has > been verified. Whether the far-end chooses to trust that or not is up to it. Clearly there's a choice; you said it right above in the last sentence. The reason I say that it's potentially misleading is because the UAS has no way to know whether to believe it or not. Since the only way to make the scheme workable is to have some conventions which SIP by definition cannot define, why not just require that those conventions be encoded in the RPI value? In that case, SIP doesn't have to make _any_ statement at all about the potential trustworthiness which is almost certain to be misunderstood if it's in the spec. Mike _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 15:35:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10712 for ; Thu, 3 Jan 2002 15:35:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA18945 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 15:35:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18360; Thu, 3 Jan 2002 15:26:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18329 for ; Thu, 3 Jan 2002 15:26:10 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10425 for ; Thu, 3 Jan 2002 15:26:06 -0500 (EST) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g03KQ7P56272; Thu, 3 Jan 2002 15:26:07 -0500 (EST) Reply-To: From: "Brett Tate" To: "'Jonathan Rosenberg'" Cc: Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time Date: Thu, 3 Jan 2002 15:28:13 -0500 Message-ID: <001101c19495$2b65bbd0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C341567.6060303@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > The ONLY thing solved by the increasing-duration > capability was to handle compliant, but > "overly zealous" user agents. There is no > disagreement that it doesn't help with dos > attacks. > > Perhaps the right solution, then, is to allow > registrars to only decrease, and to provide an > error response code to provide a general > "you're sending too fast, slow down" capability, > which would also be helpful for SUBSCRIBE, for > example, which will suffer the same problem. > > Comments? All of these same points were raised last summer around the time we were also trying to address short Session-Expires. (Sorry, I couldn't reach http://lists.bell-labs.com/pipermail/sip/ to link the thread). At that time, the decision was that the REGISTER was not intend to register services like temporary call forwarding through the use of the expires header or parameter. Nobody was overly opposed to the backward compatibility issue with rfc2543. People didn't really think reallocation of a contact to a different subscriber would really be an issue. The problem with returning an error response is that non-bis compliant UAC's would reduce the response to 400. Thus it might actually produce more registrations and restrict the user from receiving calls until customer support communicates what the timer should be. The problem with UAS extending the timer is that non-bis compliant UAC might continue to register based upon original expires. This isn't that big a deal. The registrar could kick off an email, auto-call, or begin rejecting the REGISTER to ensure the situation gets corrected. Ultimately, I don't mind which solution is chosen, I would just like to see it closed for good. If a vote is required, I'd prefer allowing the registrar to modify the expires however it desires as long as it gets communicated back to the UAC so it knows when to refresh or cancel the registration. This would help avoid the need for user reconfiguration since the UAC gives the preference and the UAS gives the decision. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 15:56:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11130 for ; Thu, 3 Jan 2002 15:56:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19690 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 15:56:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19252; Thu, 3 Jan 2002 15:45:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19221 for ; Thu, 3 Jan 2002 15:45:32 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10931 for ; Thu, 3 Jan 2002 15:45:28 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g03KivVZ006423; Thu, 3 Jan 2002 15:44:57 -0500 (EST) Message-ID: <3C34C2AD.3000301@dynamicsoft.com> Date: Thu, 03 Jan 2002 15:44:29 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C34BB38.4CADE13@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning G. Schulzrinne wrote: > Jonathan Rosenberg wrote: > >>Do you remember what the specific problem is? >> > > http://cider.caida.org/~evi/sigcomm/paper.html > > "This last example is typical of a bug in the DNS data files at the > local site. If a name that should end in a dot and therefore be absolute > has no dot, the local nameserver will add the local domain to complete > the name. A bug in at least one nameserver implementation > adds the local domain recursively until it is 256 characters long (the > limit). The WSCOOPER example has been truncated to fit the > page!" > > I'm not arguing that this is a big deal, particularly since for SIP > URLs, it's easier to tell if you need to add the domain or not. Yeah, this one seems like a non-issue. > Did >>the proxy do the wrong thing by interpreting the tel URL as a PSTN >>number? Looking at either element individually, it doesn't seem like >>either did the wrong thing, which would lead me to believe that the >>spec has to say something here so it doesn't happen. >> > > I just don't see how we can mandate the translation of user input into > protocol elements. If anything, this belongs in more informal documents > such as "Suggestions for IP phones" that Henry Sinnreich and others are > putting together. Its hard to argue with this point. I'll back off some. I still think something is needed in the base spec; possibly a statement that all proxies need to support the tel URL, along with a reasonable definition of what the semantics of a particular tel URL are when used with SIP. So long as we have a clear definition of what sip:123 v. tel:123 v. tel:+123 means, then the UI can do whatever it wants to construct a URL. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 16:17:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11519 for ; Thu, 3 Jan 2002 16:17:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20553 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 16:17:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20191; Thu, 3 Jan 2002 16:01:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20143 for ; Thu, 3 Jan 2002 16:00:59 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11223 for ; Thu, 3 Jan 2002 16:00:55 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g03L0JVZ006453; Thu, 3 Jan 2002 16:00:19 -0500 (EST) Message-ID: <3C34C647.3020202@dynamicsoft.com> Date: Thu, 03 Jan 2002 15:59:51 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org, John.Hearty@Level3.com Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C32A128.471DB380@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > Some more issues on this. > > First, if the UAS has NOT (maybe because of media direction reasons etc) > noticed the media failure the re-INVITE will be treated like a any > re-INVITE, and if the SDP hasn't changed it will simply trigger a > response... Sure. In this case, the re-invite may not help, and then the call is BYEd. > > Second, IF the UAS has noticed the media failure it would also send a > re-INVITE (possible with new SDP parameters, if new resources must be > reserved) and we may get a re-INVITE race condition (see Open Issue > #139). True, but it will get resolved, and if the re-invites don't help, a BYE would be sent (possibly by both as well). > > Third, if a intermediate SIP node (eg a SIP proxy controlling a media > server) detects the failure, it won't be able to do anything. Should it > then simply wait for the re-INVITE? What choice would it have? It can't tell there is a problem. > > Fourth, I think that in many (most?) cases the failure will be in the > network, on a IP-or-lower level, and not in the SIP end nodes, in which > cases a re-INVITE won't help anyway... True, the re-INVITE only helps when the failure is in the sip nodes. But, it provides a fairly nice way to do e2e recovery for endpoint failures, and the cost is low, I believe (may not help, but won't hurt, and is not hard to implement). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 16:18:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11556 for ; Thu, 3 Jan 2002 16:18:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20570 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 16:18:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19675; Thu, 3 Jan 2002 15:56:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19643 for ; Thu, 3 Jan 2002 15:56:03 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11124 for ; Thu, 3 Jan 2002 15:55:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g03KtMVZ006434; Thu, 3 Jan 2002 15:55:22 -0500 (EST) Message-ID: <3C34C51E.7020807@dynamicsoft.com> Date: Thu, 03 Jan 2002 15:54:54 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: John.Hearty@Level3.com, sip@ietf.org Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C319BA1.D5D15074@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > >>>However, if the nodes are separated, and eg MGCP/H.248 is used between >>>them, those protocols may define other actions to be taken when media >>>failures occur. For example, MGCP allows the media handler to RELEASE >>>the call if the media "connection" is lost, so to be able to >>>re-establish the session a whole NEW session must be setup. >>> >>> >>I think that is wrong. I don't think the media handler can release the >>call, it can only inform the MGC of errors. >> > > That is true for H.248, but when using MGCP the media handler (ie the > Media Gateway) IS allowed to release the connection and send DLCX > (DeleteConnection) to the call controller (ie the Media Gateway > Controller). This does not release any calls, it merely informs the MGC of a failed connection. The MGC can still re-invite and then re-create the connection. >>This makes no sense whatsoever to me. The UA is in the gateway, and the >>RTP session handler is in the gateway. If a gateway detects failure of >>RTP, it can certainly send a re-INVITE. >> > > Yes, IF all the resources on the PSTN (or whatever gateway we're using) > are still reserved, and the session has been "lost" only from a SIP > point of view. But, if some of the PSTN resources has also been > lost/released, sending a re-INVITE won't help, since the session would > have to be re-established also on the PSTN side. In this case, it wouldn't reinvite, since there is also a local failure that cannot be repaired. The case we are talking about here is when a UA notices a media failure, but things are fine on its side, and so it attempts to help the other side reconstitute state with a re-invite. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 3 17:07:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12430 for ; Thu, 3 Jan 2002 17:07:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22491 for sip-archive@odin.ietf.org; Thu, 3 Jan 2002 17:07:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21763; Thu, 3 Jan 2002 16:52:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21732 for ; Thu, 3 Jan 2002 16:52:47 -0500 (EST) Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12154 for ; Thu, 3 Jan 2002 16:52:42 -0500 (EST) Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id g03Lq4P31108; Thu, 3 Jan 2002 16:52:04 -0500 Message-Id: <5.1.0.14.2.20020103161641.058ef530@mail.pingtel.com> X-Sender: jbatson@mail.pingtel.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 03 Jan 2002 16:51:51 -0500 To: "Henning G. Schulzrinne" , Jonathan Rosenberg From: Jay Batson Subject: Re: [Sip] Open Issue #366: sip v. tel URL Cc: sip@ietf.org In-Reply-To: <3C34BB38.4CADE13@cs.columbia.edu> References: <3C3460AB.719771F6@cs.columbia.edu> <3C34B78C.2090004@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 03:12 PM 1/3/02, Henning G. Schulzrinne wrote: >I'm not sure how cell phones handle this - if my cell home area code is >201, but I'm roaming in 415, and then type a 7-digit number, will it be >treated as a 201 number or a 415 number? Don't quote me on this, 'cause: a) I'm not a technical expert on PSTN wireless, and b) I'm trying to dredge up cell phone behaviors from memory. But I've accidentally dialed 7-digit numbers enough times while roaming to be burned by this more than once. (No, I'm not a bozo user.... I don't consciously dial 7 digits, but occasionally am on mental auto-pilot and use speed-dials programmed into my cell phone that are just 7 digits....) My recollection of the behavior is that the "wireless network switch" (or something similar) plays me some kind of error message saying "To complete this call, you must dial the area code before the phone number," or something of the like. (Completely uninformed suppositions follow). One could hypothesize that it works this way because the "wireless switch" knows that the originating phone is "roaming," presumably because the phone had to do some kind of registration when it got powered on, and that calls coming from that phone thusly have to be fully resolved when dialed. The wireless switch thus knows enough to know that I'm roaming, but not enough to know where my home Area Code is, or whether the Area Code rules in my home area require mandatory 10 digit dialing, etc. It just knows that it needs me to dial a fully-resolved number with Area Code. (Is this because the CDR handed back to "my" wireless provider uses the fully-resolved Area Code info to help my provider know whether my call was "long distance" or not? I dunno.) I think. -jb _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 4 01:29:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20241 for ; Fri, 4 Jan 2002 01:29:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA11122 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 01:29:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02350; Fri, 4 Jan 2002 01:01:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02321 for ; Fri, 4 Jan 2002 01:01:57 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20075 for ; Fri, 4 Jan 2002 01:01:55 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0461lJ27830; Fri, 4 Jan 2002 07:01:48 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0461lhO014601; Fri, 4 Jan 2002 08:01:47 +0200 (EET) Message-ID: <3C354535.D01C0BDF@lmf.ericsson.se> Date: Fri, 04 Jan 2002 08:01:25 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> <3C33009A.6B232FF9@lmf.ericsson.se> <013501c193c7$656d6e50$01000001@dynamicsoft.com> <3C33F328.462434B8@lmf.ericsson.se> <15412.36246.307190.661368@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Mike, I am not really sure I understood your question, but I assume that you meant that you want TCP to be used for the CEO, while others can use UDP. Right? We should remember that the SIP SIGNALLING is only a small part of the messages sent during session, so from that point of view I think the session with the CEO will be established no matter what transport protocol is used, even if some UDP fragments of the INVITE is lost and must be re-sent. The MEDIA, however, will still be transported on UDP (in an IP bearer network using RTP), so if there are lots of delay and packet losses in the network your CEO isn't going to be too happy anyway - even if he got the INVITE in a "nice and reliable" way. Again, I appologise if I missunderstood your question :) Regards, Christer Holmberg Ericsson Finland Michael Thomas wrote: > > Christer Holmberg writes: > > > > Hi, > > > > The solution to the problem you describe is - SIP. If an operator has > > the problem with UDP that you describe, either in the whole of his > > network or between specific SIP nodes, he may configure the nodes to use > > TCP (or SCTP, or whatever) instead of UDP. Again, that's one of the good > > things of having a transport independent protocol. > > So what happens when the sprawling operations of > softarmor.com and mtcc.com need to put their > Very Important CEO's in touch? > > Mike _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 4 01:43:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20336 for ; Fri, 4 Jan 2002 01:43:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA11724 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 01:43:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11626; Fri, 4 Jan 2002 01:31:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11522 for ; Fri, 4 Jan 2002 01:31:12 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20286 for ; Fri, 4 Jan 2002 01:31:10 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g046V6J04978; Fri, 4 Jan 2002 07:31:06 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g046V6hO016023; Fri, 4 Jan 2002 08:31:06 +0200 (EET) Message-ID: <3C354C13.5D1E4DB5@lmf.ericsson.se> Date: Fri, 04 Jan 2002 08:30:43 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, John.Hearty@Level3.com Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C32A128.471DB380@lmf.ericsson.se> <3C34C647.3020202@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, So, to summarize, the only times this will work is when: 1. BOTH endpoints are aware of the media failure, and BOTH send a re-INVITE. 2. One endpoint and one media aware proxy are aware of the media failure, and the endpoint sends a re-INVITE. In both cases the reason for the media failure must be in the SIP nodes, on such a level that the re-INVITE will do any good. I DO agree that it is easy to implement the re-INVITE, but I still think the real-life situations where it will actually do any good are so few so the text should say "MAY send a re-INVITE". Also, if the failure in the SIP nodes which caused the media failure also caused lost of the SIP call state the re-INVITE won't help, since a tagged re-INVITE will trigger 481. >>Second, IF the UAS has noticed the media failure it would also send a >>re-INVITE (possible with new SDP parameters, if new resources must be >>reserved) and we may get a re-INVITE race condition (see Open Issue >>#139). > >True, but it will get resolved, and if the re-invites don't help, a BYE >would be sent (possibly by both as well). We should also remember that the re-INVITE race condition in this case doesn't only affect the end-nodes. Assume that BOTH endpoints notice the media failure, BOTH send re-INVITE, AND there is a media-aware proxy in the middle. If that proxy is also aware of the media failure it must be able to handle the re-INVITEs from both directions - or at least know that there will be two re-INVITEs, so it can "wait" for the end-nodes to solve the race condition... A normal proxy, which don't care about the SDP, will of course not be affected by this. Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > Christer Holmberg wrote: > > > Hi, > > > > Some more issues on this. > > > > First, if the UAS has NOT (maybe because of media direction reasons etc) > > noticed the media failure the re-INVITE will be treated like a any > > re-INVITE, and if the SDP hasn't changed it will simply trigger a > > response... > > Sure. In this case, the re-invite may not help, and then the call is BYEd. > > > > > Second, IF the UAS has noticed the media failure it would also send a > > re-INVITE (possible with new SDP parameters, if new resources must be > > reserved) and we may get a re-INVITE race condition (see Open Issue > > #139). > > True, but it will get resolved, and if the re-invites don't help, a BYE > would be sent (possibly by both as well). > > > > > Third, if a intermediate SIP node (eg a SIP proxy controlling a media > > server) detects the failure, it won't be able to do anything. Should it > > then simply wait for the re-INVITE? > > What choice would it have? It can't tell there is a problem. > > > > > Fourth, I think that in many (most?) cases the failure will be in the > > network, on a IP-or-lower level, and not in the SIP end nodes, in which > > cases a re-INVITE won't help anyway... > > True, the re-INVITE only helps when the failure is in the sip nodes. > But, it provides a fairly nice way to do e2e recovery for endpoint > failures, and the cost is low, I believe (may not help, but won't hurt, > and is not hard to implement). > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 4 08:42:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01805 for ; Fri, 4 Jan 2002 08:42:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22095 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 08:42:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21386; Fri, 4 Jan 2002 08:23:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21356 for ; Fri, 4 Jan 2002 08:22:59 -0500 (EST) Received: from alumnux.com ([202.140.147.171]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01515 for ; Fri, 4 Jan 2002 08:22:56 -0500 (EST) Received: from alumnux.com (IDENT:root@nokia.alumnus.co.in [192.168.10.22]) by alumnux.com (8.9.3/8.9.3) with ESMTP id AAA30311; Sat, 5 Jan 2002 00:24:46 +0530 Message-ID: <3C35AD85.A5C6BB6D@alumnux.com> Date: Fri, 04 Jan 2002 18:56:30 +0530 From: Rudra Dutta X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, sip@vovida.org, sip-implementors-requesto@cs.columbia.edu, innovations@ubiquity.net, sip@lists.bell-labs.com, siphon-general@lists.sourceforge.net Content-Type: multipart/alternative; boundary="------------B03C2B04CE46AC1B870EA8DB" Subject: [Sip] SIP Stack with API Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --------------B03C2B04CE46AC1B870EA8DB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Can anyone of you give me information about currently available SIP stack ? Actually I want to evaluate the available SIP stacks. It will be a great help to me if you send me the API of SIP stacks also so that I can decide to buy one. Any help will be appreciated. Thanks in advance Regards, -- Rudra Dutta Alumnus Software Limited Kolkata, India --------------B03C2B04CE46AC1B870EA8DB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,
    Can anyone of you give me information about currently available SIP stack ? Actually I want to evaluate the available SIP stacks. It will be a great help to me if you send me the API of SIP stacks also so that I can decide to buy one.

Any help will be appreciated.
Thanks in advance
Regards, 

-- 
Rudra Dutta
Alumnus Software Limited
Kolkata, India
  --------------B03C2B04CE46AC1B870EA8DB-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 4 09:10:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02702 for ; Fri, 4 Jan 2002 09:10:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA22803 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 09:10:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22231; Fri, 4 Jan 2002 08:52:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22201 for ; Fri, 4 Jan 2002 08:52:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02027; Fri, 4 Jan 2002 08:52:05 -0500 (EST) Message-Id: <200201041352.IAA02027@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 04 Jan 2002 08:52:04 -0500 Subject: [Sip] I-D ACTION:draft-schulzrinne-sip-reason-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Reason Header Field for the Session Initiation Protocol Author(s) : H. Schulzrinne, D. Oran, G. Camarillo Filename : draft-schulzrinne-sip-reason-00.txt Pages : 5 Date : 03-Jan-02 For creating services, it is often useful to know why a SIP request was issued. This document defines an optional informational header field, Reason, that provides this information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schulzrinne-sip-reason-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-schulzrinne-sip-reason-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-schulzrinne-sip-reason-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020103142402.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schulzrinne-sip-reason-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-schulzrinne-sip-reason-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020103142402.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 4 11:00:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06865 for ; Fri, 4 Jan 2002 11:00:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26463 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 11:00:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25753; Fri, 4 Jan 2002 10:40:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25722 for ; Fri, 4 Jan 2002 10:40:33 -0500 (EST) Received: from mailcity.com (fes-qout.whowhere.com [209.185.123.96]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05919 for ; Fri, 4 Jan 2002 10:40:30 -0500 (EST) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri Jan 4 07:39:48 2002 To: sip@ietf.org Date: Fri, 04 Jan 2002 10:39:48 -0500 From: "Info Van" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: infovaan@lycos.com X-Mailer: MailCity Service X-Priority: 3 Subject: Re: [Sip] Open Issue #366: sip v. tel URL X-Sender-Ip: 64.66.32.130 Organization: Lycos Mail (http://mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit hi, i am not very experience about SIP or MobileIP so plz excuse me if I say something very naive here. but the heuristics you are talking about, won't they be very difficult (if not impossible) to formulate for SIP UA's using mobile IP where there is almost (or absolutely) no notion (information) of location related to the UA, so how does this database of appropriate PSAP help ?? rather if there is some extension by virtue of which a UA (optionally, to be 911 conformant) sends additional Location: information to the Registrar ?? I mean "real" GPS (or Geographic) location. my 2 cents, bdutta. --- >> >> My outbound proxy may never move, so this is >> not in any way generalizable. I understand that >> some people want to deploy proxies that way, >> but I strenuously object to this hack being the >> mechanism by which we localize 911. > >I wouldn't, either. However, I'm trying to find heuristics that are more >likely to work in the short term. I've made proposals (and will spell >them out in more detail soon) on how to make it possible for any entity >to locate the appropriate PSAP. However, this requires a database that >somebody needs to build and maintain. -- Click here for your very own create-a-date adventure from MatchMaker Go to http://ecard.matchmaker.com/dating.html _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 4 11:43:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08130 for ; Fri, 4 Jan 2002 11:43:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28212 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 11:43:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27056; Fri, 4 Jan 2002 11:24:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27025 for ; Fri, 4 Jan 2002 11:24:10 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07579 for ; Fri, 4 Jan 2002 11:24:06 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g04GNEw28256; Fri, 4 Jan 2002 08:23:15 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP60634; Fri, 4 Jan 2002 08:23:01 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA11713; Fri, 4 Jan 2002 08:23:34 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15413.55045.821171.732298@thomasm-u1.cisco.com> Date: Fri, 4 Jan 2002 08:23:33 -0800 (PST) To: Christer Holmberg Cc: Michael Thomas , Dean Willis , sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations In-Reply-To: <3C354535.D01C0BDF@lmf.ericsson.se> References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> <3C33009A.6B232FF9@lmf.ericsson.se> <013501c193c7$656d6e50$01000001@dynamicsoft.com> <3C33F328.462434B8@lmf.ericsson.se> <15412.36246.307190.661368@thomasm-u1.cisco.com> <3C354535.D01C0BDF@lmf.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sorry -- perhaps a bit too obscure. The point I'm making is that an "operator" may in fact be very, very small so that any supposed site-wide policy may be inconsequential, and the likelihood of peering arrangements negligible. SIP needs to work in cross realm settings large and small equally well. Therefore we can't hand wave this issue away by saying that it can be dealt with as a general issue with peering with well defined peering points. That is very likely how large operators will set up their networks, but that does not scale for lots of very small SIP deployments. Mike Christer Holmberg writes: > > Hi Mike, > > I am not really sure I understood your question, but I assume that you > meant that you want TCP to be used for the CEO, while others can use > UDP. Right? > > We should remember that the SIP SIGNALLING is only a small part of the > messages sent during session, so from that point of view I think the > session with the CEO will be established no matter what transport > protocol is used, even if some UDP fragments of the INVITE is lost and > must be re-sent. > > The MEDIA, however, will still be transported on UDP (in an IP bearer > network using RTP), so if there are lots of delay and packet losses in > the network your CEO isn't going to be too happy anyway - even if he got > the INVITE in a "nice and reliable" way. > > Again, I appologise if I missunderstood your question :) > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Michael Thomas wrote: > > > > Christer Holmberg writes: > > > > > > Hi, > > > > > > The solution to the problem you describe is - SIP. If an operator has > > > the problem with UDP that you describe, either in the whole of his > > > network or between specific SIP nodes, he may configure the nodes to use > > > TCP (or SCTP, or whatever) instead of UDP. Again, that's one of the good > > > things of having a transport independent protocol. > > > > So what happens when the sprawling operations of > > softarmor.com and mtcc.com need to put their > > Very Important CEO's in touch? > > > > Mike _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 4 12:52:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09597 for ; Fri, 4 Jan 2002 12:52:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA01071 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 12:52:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00841; Fri, 4 Jan 2002 12:42:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA00806 for ; Fri, 4 Jan 2002 12:42:00 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09391 for ; Fri, 4 Jan 2002 12:41:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g04HfEVZ007065; Fri, 4 Jan 2002 12:41:15 -0500 (EST) Message-ID: <3C35E91E.5050703@dynamicsoft.com> Date: Fri, 04 Jan 2002 12:40:46 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org, John.Hearty@Level3.com Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C354C13.5D1E4DB5@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > So, to summarize, the only times this will work is when: > > 1. BOTH endpoints are aware of the media failure, and BOTH send a > re-INVITE. > > 2. One endpoint and one media aware proxy are aware of the media > failure, and the endpoint sends a re-INVITE. I have no idea what a media aware proxy is or why it matters. The mechanism handles the case where one of the two UAs in a dialog has failed, and a backup is to take its place. Rather than have state replication, the state at the backup is reconsituted via a re-invite from the far side. This works for a large class of UA, including conferencing servers and dialog servers. It would also work for any phone or PC app that could quickly recover after a failure. > > In both cases the reason for the media failure must be in the SIP nodes, > on such a level that the re-INVITE will do any good. Yes. > > I DO agree that it is easy to implement the re-INVITE, but I still think > the real-life situations where it will actually do any good are so few > so the text should say "MAY send a re-INVITE". You miss the point. The strength of the requirement is not related to the probability of its efficacy. Strengths are determined based on whether something won't work as expected if its not followed. If I am building a vxml server or a conference server, and I want to take advantage of this feature of sip to recover calls, I can only do so if the strength is SHOULD or MUST. If its MAY, I cannot count on it, and thus must engineer the ability to replicate dialog and session state to backups. > > Also, if the failure in the SIP nodes which caused the media failure > also caused lost of the SIP call state the re-INVITE won't help, since a > tagged re-INVITE will trigger 481. No, the re-invite can also re-establish dialog state in the backup. You should read http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt if you have not alraedy. >>True, but it will get resolved, and if the re-invites don't help, a BYE >>would be sent (possibly by both as well). >> > > We should also remember that the re-INVITE race condition in this case > doesn't only affect the end-nodes. Assume that BOTH endpoints notice the > media failure, BOTH send re-INVITE, AND there is a media-aware proxy in > the middle. If that proxy is also aware of the media failure it must be > able to handle the re-INVITEs from both directions - or at least know > that there will be two re-INVITEs, so it can "wait" for the end-nodes to > solve the race condition... A normal proxy, which don't care about the > SDP, will of course not be affected by this. Any media-aware intermediarty, such as a firewall proxy, must already be able to worry about the glare scenario. There is nothing it needs to do, since the endpoints will resolve the problem for it. In fact, so long as the firewall proxy handles the case where a re-invite fails, it will properly handle glare resolution. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 13:06:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09797 for ; Fri, 4 Jan 2002 13:06:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01733 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 13:06:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01150; Fri, 4 Jan 2002 12:56:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA01119 for ; Fri, 4 Jan 2002 12:56:30 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09678 for ; Fri, 4 Jan 2002 12:56:23 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g04HuGVZ007069; Fri, 4 Jan 2002 12:56:16 -0500 (EST) Message-ID: <3C35ECA2.2030102@dynamicsoft.com> Date: Fri, 04 Jan 2002 12:55:46 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Terry L Anderson CC: sip@ietf.org Subject: Re: [Sip] Open Issue #342: SDP in 488 References: <3C34755C.D6474D27@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Terry L Anderson wrote: > Below >>There is another complication, which is that if we specify that you >>need >>to return SDP in a 488/606, and an OPTIONS response, then we need to >>specify how to format that SDP. That would either be a new spec in >>mmusic, or more likely, the simcap spec in mmusic. That introduces >>another dependency, plus its not entirely clear to me yet that simcap >>is quite on target for this. >> > > I thought it was specified, although perhaps you believe it needs more > detail. In bis-04 section 8 and the example in 20.8 seemed clear enough > to > me. Its just an example. Examples don't specify normative text. Of course much of this is gone in bis-05 (removed along with the > reset of > the SDP discussion) although the body (and payload list) is still > present in > the example in 11.2 and 11 suggests codecs as one of the types of things > that > can be discovered with OPTIONS. > > I take it you want to remove the body from OPTIONS response as well then > and > remove the word "codec" from the description in 11. Well, I was hoping for 488, I need to remove it from OPTIONS to in order to avoid the dependencies, but I am not so hopeful. > > I always felt codec negotiation was the most valuable use of OPTIONS > (and > 488/606 response). Otherwise finding a common codec is a trial and > error > process. It is common for gateways to support only symmetric payloads > and > single audio codec at a time (with telephone-event possibly added). If > there > is no way to query the other end for a list of supported codecs it is > difficult to find one in common. Thats not true at all. This is why simcap was developed. > > I admit that removing the SDP details from the SIP spec makes this more > difficult but I thought that the phrase in bis-04 section 8 (and earlier > bis): > > "The response MAY contain a message body indicating the capabilities > of > the end > system (rather than properties of any existing call)." > > was clear enough (that any payload list should be all those supported > rather > than those desired for a single call) and never mentioned SDP. My experiences with SIP/SDP is that you'd be amazed how easily it is for people to come up with all kinds of creative interpretations of text that is not extremely explicit and direct. The fact is, if we want to have OPTIONS 488/606 indicate capabilities with SDP, we need to have an explicit way of how that is done, period. Since I suspect that I won't be able to convince people to remove this, I guess i need to go through simcap with a fine tooth comb and make sure its up to snuff. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 13:46:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10884 for ; Fri, 4 Jan 2002 13:46:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA02866 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 13:46:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02054; Fri, 4 Jan 2002 13:21:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01984 for ; Fri, 4 Jan 2002 13:21:53 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10014; Fri, 4 Jan 2002 13:21:51 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA18657; Fri, 4 Jan 2002 10:21:04 -0800 (PST) Message-ID: <3C35F2B3.FD96229B@cisco.com> Date: Fri, 04 Jan 2002 13:21:39 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Drage, Keith (Keith)" , sip@ietf.org, mmusic@ietf.org, confctrl@isi.edu Subject: Re: [MMUSIC] Re: [Sip] Open Issue #150: too many ways of saying " don't send me media" References: <3C22B0AC.2E1DDE79@cisco.com> <3C2A4972.7050101@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Flemming Andreasen wrote: > > > > > >>The semantics are: > >> > >>c=0.0.0.0: will cease reception of RTP and RTCP, no longer the > >>recommended way to do hold, has issues with SRTP keying, ipv6, > >>connection oriented media, etc. Generally bad. > >> > >>a=inactive/sendonly - stops only RTP > >> > >>port 0: turns of media streams - safe to unload codecs, etc. > >> > >>bw=0: will turn off reception of RTP and RTCP > >> > > > > Do we really need the "bw" one ? > > No, its not really NEEDED. The point Henning had made at IETF is that > the treatment for any bandwidth number is well defined; in that case, > disallowing zero is a special case. I see no reason to disallow it as a > special case when it has defined meaning for all values. > I'm not sure I agree with this. Let's say I specify a bw of 1 kilobit, and the only codec supported currently is G.711. What do I do ? There are several parameters that can have more or less sensible values associated with them and having a bandwidth specify less than the current codecs is not sensible IMO. All you are doing is defining yet another implicit way of signaling something for which there is already explicit signaling support in place. I'd rather reduce the number of well-defined options for expressing something than increasing it. Not a big deal either way to me, but more of a general design principle - I'll leave it up to you. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 17:04:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14914 for ; Fri, 4 Jan 2002 17:04:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA08529 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 17:04:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07865; Fri, 4 Jan 2002 16:48:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07795 for ; Fri, 4 Jan 2002 16:48:29 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14574; Fri, 4 Jan 2002 16:48:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g04LlqVZ007275; Fri, 4 Jan 2002 16:47:52 -0500 (EST) Message-ID: <3C3622EB.5040707@dynamicsoft.com> Date: Fri, 04 Jan 2002 16:47:23 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I've been combing through the sip-implementors and sip lists, looking for open issues that need resolution, or comments that needed addressing in the specification. This is the source of much of my spamming on sip-implementors.... An issue that has arisen time and time and time again, is the need for an endpoint to indicate in its SDP that it can do any one of these three codecs, but can only do one at a time, that is, it doesn't support dynamically changing codecs on the fly. Since the question has been asked 1/2 dozen times on sip-implementors, and concerns both sip and mmusic, I have cross posted. If the thread takes off we'll trim it to a single list. The response I gave to people who asked about it, was that this was what simcap (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.txt) was for, and to go read that. However, after a discussion with Flemming, it appears I misinterpreted that specification. It is merely a declaration of the codes that an endpoint can support. This information would be used in subsequent offer/answer exchanges, so that a UA can make an offer without having to guess whether it would or wouldn't be accepted. I was under the false impression that the point of simcap was to, in fact, solve this particular problem of one-codec-at-a-time for the initial exchange. So, we are faced with this gap of how to handle this problem. I see a few solutions: 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. The offer would list ALL the codecs the UA can do, the counter-offer is the subset that the other UA can do, and the answer can reduce it further to just a few. This solution would require us to define this 3-way handshake somewhere; that is still being debated as an open issue. Bill has included this already in manyfolks, partly to solve this problem (or maybe entirely to solve this problem). 2. Define a backwards compatible usage of simcap to modify the offer-answer exchange. The offer would contain an m line with a single codec choice (in this particular case where it can do only one a time), but the offer would include simcap attributes indicating support for other codecs. The answerer could choose from amongst those codecs in formulating the answer. So, for example: Offer: m=audio 8778 RTP/AVP 0 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 This offer means that the offerer is definitely using PCMU with someone that doesn't understand simcap, but is indicating they can also do codecs 1 and 2 (and each of them with rfc2833). The answerer could pick one of those alternate cdsc in the answer: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event We would probably need to define an additional attribute in the SDP that indicates that this "simcap effects the m line selection" semantic is being followed. This approach may confused intermediaries that are assuming a subset of codecs in the answer. 3. Define a sort-of backwards compatible usage of simcap with offer/answer In this model, the offerer lists all codecs they can do in the offer. They include simcap declarations as well. As with normal offer/answer, the answerer has to pick a subset, but they use the simcap declarations to help them pick a subset which is an allowed capability. So, in the example above where the caller can do codecs 0,2,3,4 along with 76, but only ONE of 0,2,3,4 at a time, the O/A would look like this: OFFER: m=audio 8778 RTP/AVP 0 1 2 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 ANSWER: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event If, however, the UAS doesn't understand simcap, its possible that they'll return an SDP listing all four codecs, and possibly change them on the fly. That can be fixed, in general, by another re-invite which lists only a single codec. This will work, but might cause an RTT worth of media to be sent using a codec different from the one the UAC "loaded" into the DSP. 4. Declare that simcap is overkill for this one problem, and define a single attribute, a=pickone, which says to choose only one of the codecs in the m line. The "I can do one of N, but only one at a time" problem, IMHO, the only capability problem that anyone actually has in real usage. I will note that, in fact, this is the only capabilities question ever asked on sip-implementors. A single attribute would easily solve it. If you want to do rfc2833 along with any one of N other codecs, you could use fid along with this, to include an m line with the rfc2833, and then another m line with the N codecs and the a=pickone attribute. One way or another, we need to solve this problem. My apologies for bringing this up so late, but I had thought it was solved (I thought it implied approach #3 above).... comments on the various alternatives? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 17:05:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14982 for ; Fri, 4 Jan 2002 17:05:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA08543 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 17:05:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07648; Fri, 4 Jan 2002 16:40:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA07616 for ; Fri, 4 Jan 2002 16:40:29 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14474 for ; Fri, 4 Jan 2002 16:40:26 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g04LeRS05460; Fri, 4 Jan 2002 16:40:27 -0500 (EST) Received: from lucent.com (pctla2 [135.3.130.26]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id QAA27688; Fri, 4 Jan 2002 16:40:26 -0500 (EST) Message-ID: <3C362095.D101759B@lucent.com> Date: Fri, 04 Jan 2002 16:37:26 -0500 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #342: SDP in 488 References: <3C34755C.D6474D27@lucent.com> <3C35ECA2.2030102@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------8529D8CFBAB683B1A0EA3EDF" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------8529D8CFBAB683B1A0EA3EDF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit See below Jonathan Rosenberg wrote: > Terry L Anderson wrote: > > > Below > > >>There is another complication, which is that if we specify that you > >>need > >>to return SDP in a 488/606, and an OPTIONS response, then we need to > >>specify how to format that SDP. That would either be a new spec in > >>mmusic, or more likely, the simcap spec in mmusic. That introduces > >>another dependency, plus its not entirely clear to me yet that simcap > >>is quite on target for this. > >> > > > > I thought it was specified, although perhaps you believe it needs more > > detail. In bis-04 section 8 and the example in 20.8 seemed clear enough > > to > > me. > > Its just an example. Examples don't specify normative text. True but I thought it illustrated the intent of the sentence in section 8 which is normative. > Of course much of this is gone in bis-05 (removed along with the > > reset of > > the SDP discussion) although the body (and payload list) is still > > present in > > the example in 11.2 and 11 suggests codecs as one of the types of things > > that > > can be discovered with OPTIONS. > > > > I take it you want to remove the body from OPTIONS response as well then > > and > > remove the word "codec" from the description in 11. > > Well, I was hoping for 488, I need to remove it from OPTIONS to in order > to avoid the dependencies, but I am not so hopeful. > > > > > I always felt codec negotiation was the most valuable use of OPTIONS > > (and > > 488/606 response). Otherwise finding a common codec is a trial and > > error > > process. It is common for gateways to support only symmetric payloads > > and > > single audio codec at a time (with telephone-event possibly added). If > > there > > is no way to query the other end for a list of supported codecs it is > > difficult to find one in common. > > Thats not true at all. This is why simcap was developed. I agree simcap helps, but I don't see how to use this in SIP without 488/OPTIONS. simcap gives a way to know whether later reINVITEs to other codec are likely to succeed (e.g, indicate capability of telephone-event without starting it initially), but say UA1 sends an INVITE with m line using 18 but a=cdsc's indicating support for 0 and 4. If UA2 cannot support 18 but CAN support 0 and/or 4, what does it do? It must 488/606 the call. Should UA2 then INVITE with m line of 0 or should the new INVITE still come from UA1? I assume UA1 and so UA2 must still inform UA1 of its capabilities by sending a body in 488/606. Doing this with cdsc rather than m lines is certainly clearer, but UA2 still needs to send a body. > > > > I admit that removing the SDP details from the SIP spec makes this more > > difficult but I thought that the phrase in bis-04 section 8 (and earlier > > bis): > > > > "The response MAY contain a message body indicating the capabilities > > of > > the end > > system (rather than properties of any existing call)." > > > > was clear enough (that any payload list should be all those supported > > rather > > than those desired for a single call) and never mentioned SDP. > > My experiences with SIP/SDP is that you'd be amazed how easily it is for > people to come up with all kinds of creative interpretations of text > that is not extremely explicit and direct. The fact is, if we want to > have OPTIONS 488/606 indicate capabilities with SDP, we need to have an > explicit way of how that is done, period. > > Since I suspect that I won't be able to convince people to remove this, > I guess i need to go through simcap with a fine tooth comb and make sure > its up to snuff. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------8529D8CFBAB683B1A0EA3EDF Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard --------------8529D8CFBAB683B1A0EA3EDF-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 17:24:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15260 for ; Fri, 4 Jan 2002 17:24:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA08792 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 17:24:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08636; Fri, 4 Jan 2002 17:11:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08612 for ; Fri, 4 Jan 2002 17:11:46 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15054 for ; Fri, 4 Jan 2002 17:11:44 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 419324CE54 for ; Fri, 4 Jan 2002 17:11:46 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA28545; Fri, 4 Jan 2002 17:11:43 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id RAA23925; Fri, 4 Jan 2002 17:13:44 -0500 (EST) Date: Fri, 4 Jan 2002 17:13:44 -0500 (EST) Message-Id: <200201042213.RAA23925@fish.research.att.com> To: sip@ietf.org Subject: [Sip] Last Call comments on draft-ietf-sip-refer-02 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org When I did my review of draft-ietf-sip-refer-02 prior to the last call period, I missed the example that included "method=" as a URL parameter in the Refer-to header. With this URL parameter there are a few additional comments I wish to make. First, it is necessary to register the header name "Method:", since it would otherwise be ambiguous whether a URL parameter on Refer-To is giving a value for the method in the Request-URI, or the value for a header to be included in the request. Secondly, and more importantly, some additional text is needed to describe the formation of a request using the method parameter. (1) If the method is only vaid within an existing dialog, then certain header fields (e.g. CSeq) need to be provided by the UA that accepted the REFER request, with values determined by the current state of the existing dialog. (2) Security considerations need to discuss whether other dialog-dependent headers (e.g. From, To, Call-ID) need to be specified in the Refer-To or can be supplied by the UA. (3) The final sentence of section 3.5.1 implies that a REFER with a sip: URL always sends INVITE - this needs to be fixed. (4) Some default action needs to be specified for cases where the UA does not understand the method value; is this handled the same as not understanding the URL scheme? I presume that the recommended policy for methods within existing dialogs will prevent the obvious busy-signal-fix of sending the destination REFER;method=BYE without any knowledge of the active dialog identification. Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 17:42:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15513 for ; Fri, 4 Jan 2002 17:42:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09348 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 17:42:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08853; Fri, 4 Jan 2002 17:27:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08822 for ; Fri, 4 Jan 2002 17:27:43 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15301 for ; Fri, 4 Jan 2002 17:27:40 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA29367; Fri, 4 Jan 2002 14:25:33 -0800 (PST) Message-ID: <3C362C00.56A7E641@cisco.com> Date: Fri, 04 Jan 2002 17:26:09 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Mark Watson , "'Jonathan Rosenberg'" , brett@broadsoft.com, sip@ietf.org Subject: Re: Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To) References: <15412.44924.974380.301716@thomasm-u1.cisco.com> <3C34B67E.A5D7A7F8@cisco.com> <15412.47796.886573.183390@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Flemming Andreasen writes: > > > The issue here is not whether a particular > > > business model is good or bad, but whether the > > > protocol should assert whether something is > > > verified or not, and expect something on the far > > > end to take action based on that tag. > > > > It doesn't expect the far end to do anything - it merely asserts that is has > > been verified. Whether the far-end chooses to trust that or not is up to it. > > Clearly there's a choice; you said it right above > in the last sentence. The reason I say that it's > potentially misleading is because the UAS has > no way to know whether to believe it or not. Very true - it all comes down to trust. > Since > the only way to make the scheme workable is to > have some conventions which SIP by definition cannot > define, why not just require that those conventions > be encoded in the RPI value? I'm not sure I understand the proposal - can you elaborate ? > In that case, SIP doesn't > have to make _any_ statement at all about the potential > trustworthiness which is almost certain to be > misunderstood if it's in the spec. > Maybe I'm misunderstanding, but given the current state of affairs, I still believe there is value in saying "no, this is definitely not verified", or "I claim this has been verified, and how much trust you want to place in that is up to you" as opposed to saying nothing at all. -- Flemming > > Mike -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 18:07:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15812 for ; Fri, 4 Jan 2002 18:07:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10204 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 18:07:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09422; Fri, 4 Jan 2002 17:47:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09391 for ; Fri, 4 Jan 2002 17:47:01 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15556 for ; Fri, 4 Jan 2002 17:46:58 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g04Mil3a022999; Fri, 4 Jan 2002 17:44:47 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 17:46:30 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E915@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Last Call comments on draft-ietf-sip-refer-02 Date: Fri, 4 Jan 2002 17:46:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, January 04, 2002 4:14 PM > To: sip@ietf.org > Subject: [Sip] Last Call comments on draft-ietf-sip-refer-02 > > > When I did my review of draft-ietf-sip-refer-02 prior to the > last call period, I missed the example that included "method=" > as a URL parameter in the Refer-to header. With this URL > parameter there are a few additional comments I wish to make. > > First, it is necessary to register the header name "Method:", > since it would otherwise be ambiguous whether a URL parameter on > Refer-To is giving a value for the method in the Request-URI, > or the value for a header to be included in the request. I don't see this ambiguity, and I apologize for not understanding the question earlier. It is clearly a URL parameter specifying the method to be used, just as if the URL had appeared on a web page. For it to be a header to be included in the request, it would have to be represented as a URL header parameter - after a question mark, such as: sip:foo@bar?method=INVITE Am I still missing your point? > > Secondly, and more importantly, some additional text is needed > to describe the formation of a request using the method parameter. This text is actually needed for the more general case of how to form a request from a URL (how do I form a request after clicking on a URL on a web page, or accepting a URL with the values you mention that has been manually entered into my phone?). I've already added a section on forming requests from a URI to the description of the SIP URI in the bis draft dealing with exactly these issues (1,2 and 4 anyhow). I will fix 3) in the REFER draft. > (1) If the method is only vaid within an existing dialog, > then certain header fields (e.g. CSeq) need to be provided by > the UA that accepted the REFER request, with values determined > by the current state of the existing dialog. > (2) Security considerations need to discuss whether > other dialog-dependent headers (e.g. From, To, Call-ID) need > to be specified in the Refer-To or can be supplied by the UA. > (3) The final sentence of section 3.5.1 implies that > a REFER with a sip: URL always sends INVITE - this needs to > be fixed. > (4) Some default action needs to be specified for > cases where the UA does not understand the method value; > is this handled the same as not understanding the URL scheme? > > I presume that the recommended policy for methods within existing > dialogs will prevent the obvious busy-signal-fix of sending > the destination REFER;method=BYE without any knowledge of the > active dialog identification. Without the active dialog identification, even if the REFERed party accepts the REFER and issues a BYE, its going to get 481ed. > > Bill Marshall > wtm@research.att.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 18:11:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15887 for ; Fri, 4 Jan 2002 18:11:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10247 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 18:11:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09625; Fri, 4 Jan 2002 17:51:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09474 for ; Fri, 4 Jan 2002 17:51:50 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15610; Fri, 4 Jan 2002 17:51:47 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g04MpHZ03015; Fri, 4 Jan 2002 17:51:17 -0500 (EST) Received: from lucent.com (pctla2 [135.3.130.26]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id RAA00051; Fri, 4 Jan 2002 17:51:16 -0500 (EST) Message-ID: <3C36312F.F4E4CAAA@lucent.com> Date: Fri, 04 Jan 2002 17:48:15 -0500 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3622EB.5040707@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------AC8BF07BF7B7D127730CD650" Subject: [Sip] Re: [Sip-implementors] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------AC8BF07BF7B7D127730CD650 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > I've been combing through the sip-implementors and sip lists, looking > for open issues that need resolution, or comments that needed addressing > in the specification. This is the source of much of my spamming on > sip-implementors.... > > An issue that has arisen time and time and time again, is the need for > an endpoint to indicate in its SDP that it can do any one of these three > codecs, but can only do one at a time, that is, it doesn't support > dynamically changing codecs on the fly. Since the question has been > asked 1/2 dozen times on sip-implementors, and concerns both sip and > mmusic, I have cross posted. If the thread takes off we'll trim it to a > single list. > > The response I gave to people who asked about it, was that this was what > simcap > (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.txt) > was for, and to go read that. However, after a discussion with Flemming, > it appears I misinterpreted that specification. It is merely a > declaration of the codes that an endpoint can support. This information > would be used in subsequent offer/answer exchanges, so that a UA can > make an offer without having to guess whether it would or wouldn't be > accepted. I was under the false impression that the point of simcap was > to, in fact, solve this particular problem of one-codec-at-a-time for > the initial exchange. > > So, we are faced with this gap of how to handle this problem. I see a > few solutions: > > 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. > > The offer would list ALL the codecs the UA can do, the counter-offer is > the subset that the other UA can do, and the answer can reduce it > further to just a few. > > This solution would require us to define this 3-way handshake somewhere; > that is still being debated as an open issue. Bill has included this > already in manyfolks, partly to solve this problem (or maybe entirely to > solve this problem). > > 2. Define a backwards compatible usage of simcap to modify the > offer-answer exchange. > > The offer would contain an m line with a single codec choice (in this > particular case where it can do only one a time), but the offer would > include simcap attributes indicating support for other codecs. The > answerer could choose from amongst those codecs in formulating the > answer. So, for example: > > Offer: > > m=audio 8778 RTP/AVP 0 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > > This offer means that the offerer is definitely using PCMU with someone > that doesn't understand simcap, but is indicating they can also do > codecs 1 and 2 (and each of them with rfc2833). The answerer could pick > one of those alternate cdsc in the answer: > > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > We would probably need to define an additional attribute in the SDP that > indicates that this "simcap effects the m line selection" semantic is > being followed. > > This approach may confused intermediaries that are assuming a subset of > codecs in the answer. > > 3. Define a sort-of backwards compatible usage of simcap with offer/answer > > In this model, the offerer lists all codecs they can do in the offer. > They include simcap declarations as well. As with normal offer/answer, > the answerer has to pick a subset, but they use the simcap declarations > to help them pick a subset which is an allowed capability. So, in the > example above where the caller can do codecs 0,2,3,4 along with 76, but > only ONE of 0,2,3,4 at a time, the O/A would look like this: > > OFFER: > > m=audio 8778 RTP/AVP 0 1 2 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > > ANSWER: > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > If, however, the UAS doesn't understand simcap, its possible that > they'll return an SDP listing all four codecs, and possibly change them > on the fly. That can be fixed, in general, by another re-invite which > lists only a single codec. This will work, but might cause an RTT worth > of media to be sent using a codec different from the one the UAC > "loaded" into the DSP. > > 4. Declare that simcap is overkill for this one problem, and define a > single attribute, a=pickone, which says to choose only one of the codecs > in the m line. > > The "I can do one of N, but only one at a time" problem, IMHO, the only > capability problem that anyone actually has in real usage. I will note > that, in fact, this is the only capabilities question ever asked on > sip-implementors. > > A single attribute would easily solve it. If you want to do rfc2833 > along with any one of N other codecs, you could use fid along with this, > to include an m line with the rfc2833, and then another m line with the > N codecs and the a=pickone attribute. simcap is indeed overkill for this and I like new attribute as long as we relax the requirement currently in offer-answer: "Once the offerer has sent the offer, it MUST be prepared to receive media described by that offer." If this is not relaxed the offerer cannot know which of the list of codecs to receive with and may not be able to listen with all of them until receiving the answer. Of course simcap can still be used in addition to this to indicate media that can be supported but not initially opened (e.g., rfc2833). > > > One way or another, we need to solve this problem. My apologies for > bringing this up so late, but I had thought it was solved (I thought it > implied approach #3 above).... comments on the various alternatives? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------AC8BF07BF7B7D127730CD650 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard --------------AC8BF07BF7B7D127730CD650-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 18:11:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15904 for ; Fri, 4 Jan 2002 18:11:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10263 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 18:11:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09754; Fri, 4 Jan 2002 17:57:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09725 for ; Fri, 4 Jan 2002 17:57:16 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15667 for ; Fri, 4 Jan 2002 17:57:13 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 0338A4CE1C; Fri, 4 Jan 2002 17:57:13 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA29040; Fri, 4 Jan 2002 17:57:10 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id RAA58169; Fri, 4 Jan 2002 17:58:59 -0500 (EST) Date: Fri, 4 Jan 2002 17:58:59 -0500 (EST) Message-Id: <200201042258.RAA58169@fish.research.att.com> Subject: RE: [Sip] Last Call comments on draft-ietf-sip-refer-02 To: rsparks@dynamicsoft.com Cc: sip@ietf.org Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Regarding the ambiguity between headers and method parameter, I missed the distinction between "?" and ";" following the destination URL. So this isn't a problem with "method". The original comment remains, though, about to-tag and from-tag being ambiguous between headers of that name and tags on a To/From header. > Without the active dialog identification, even if the REFERed > party accepts the REFER and issues a BYE, its going to get > 481ed. Unless the UA default action is to insert From/To/Call-ID from the active dialog, like it needs to do for the CSeq header. Hopefully no implementation would do that. Bill Marshall wtm@research.att.com -----original message----- From: Robert Sparks To: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Last Call comments on draft-ietf-sip-refer-02 Date: Fri, 4 Jan 2002 17:46:30 -0500 > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, January 04, 2002 4:14 PM > To: sip@ietf.org > Subject: [Sip] Last Call comments on draft-ietf-sip-refer-02 > > > When I did my review of draft-ietf-sip-refer-02 prior to the > last call period, I missed the example that included "method=" > as a URL parameter in the Refer-to header. With this URL > parameter there are a few additional comments I wish to make. > > First, it is necessary to register the header name "Method:", > since it would otherwise be ambiguous whether a URL parameter on > Refer-To is giving a value for the method in the Request-URI, > or the value for a header to be included in the request. I don't see this ambiguity, and I apologize for not understanding the question earlier. It is clearly a URL parameter specifying the method to be used, just as if the URL had appeared on a web page. For it to be a header to be included in the request, it would have to be represented as a URL header parameter - after a question mark, such as: sip:foo@bar?method=INVITE Am I still missing your point? > > Secondly, and more importantly, some additional text is needed > to describe the formation of a request using the method parameter. This text is actually needed for the more general case of how to form a request from a URL (how do I form a request after clicking on a URL on a web page, or accepting a URL with the values you mention that has been manually entered into my phone?). I've already added a section on forming requests from a URI to the description of the SIP URI in the bis draft dealing with exactly these issues (1,2 and 4 anyhow). I will fix 3) in the REFER draft. > (1) If the method is only vaid within an existing dialog, > then certain header fields (e.g. CSeq) need to be provided by > the UA that accepted the REFER request, with values determined > by the current state of the existing dialog. > (2) Security considerations need to discuss whether > other dialog-dependent headers (e.g. From, To, Call-ID) need > to be specified in the Refer-To or can be supplied by the UA. > (3) The final sentence of section 3.5.1 implies that > a REFER with a sip: URL always sends INVITE - this needs to > be fixed. > (4) Some default action needs to be specified for > cases where the UA does not understand the method value; > is this handled the same as not understanding the URL scheme? > > I presume that the recommended policy for methods within existing > dialogs will prevent the obvious busy-signal-fix of sending > the destination REFER;method=BYE without any knowledge of the > active dialog identification. Without the active dialog identification, even if the REFERed party accepts the REFER and issues a BYE, its going to get 481ed. > > Bill Marshall > wtm@research.att.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 19:00:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16409 for ; Fri, 4 Jan 2002 19:00:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA11373 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 19:00:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11155; Fri, 4 Jan 2002 18:49:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11080 for ; Fri, 4 Jan 2002 18:49:47 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16313; Fri, 4 Jan 2002 18:49:43 -0500 (EST) Received: from Software.Mitel.COM (software [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id SAA25089; Fri, 4 Jan 2002 18:49:03 -0500 (EST) Received: from pc3002 ([134.199.77.12]) by Software.Mitel.COM (V8/MAIL-HUB-2.0) with ESMTP id SAA13790; Fri, 4 Jan 2002 18:49:02 -0500 (EST) Reply-To: From: "Jerry Yin" To: "'Jonathan Rosenberg'" , , , Date: Fri, 4 Jan 2002 18:49:27 -0500 Message-ID: <000401c1957a$72fce690$0c4dc786@pc3002.mitel.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 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3C3622EB.5040707@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Subject: [Sip] RE: [Sip-implementors] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi there, After I read the simcap (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx t), I found that it is not backwards compatible with the SDP (RFC 2327). Here's my comments. 1. the rtpmap's format in RFC 2327 is a=rtpmap: /[/]. While in simcap, it is : a=rtpmap: telephone-event Where is the "telephone-event" defined as an encoding name? If the UA is implemented according to RFC 2327, how can it talk to the UAs implemented according to the simcap? 2. The "m=" header and "a=rtpmap" in RFC 2327 is good enough to describe the media attributes already. I don't know why it is necessary to define a new attributes of "a=cdsc" and "a=cpar". There are some redundant information here, I think. 3. If we want to describe a subset of capabilities among all capabilities the SDP claimed, we can simply introduce one new attribute to describe the subset. For example, a=subset subset_codec_number : total_codec_number. This way, even some UAs don't understand a = subset, they still can talk with the one supports this attribute by at list one media streaming. Here's an example: v=0 o=- 25678 753849 IN IP4 128.96.41.1 s=- c=IN IP4 128.96.41.1 t=0 0 m=audio 3456 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 a=subset 2:3 m=video 3458 RTP/AVP 26 31 a=rtpmap:26 JPEG/90000 a=rtpmap:31 H261/90000 a=subset 1:2 This packet means the sender can support two audio streams among three different codecs {L8, L16, and L16-stereo} and one video stream of JPEG or H261. Above all, it is not a good idea to introduce new headers only if 1) backwards compatible, 2) really necessary and can solve problems, 3) easy to implement. Thanks, Jerry Yin > -----Original Message----- > From: sip-implementors-admin@cs.columbia.edu > [mailto:sip-implementors-admin@cs.columbia.edu]On Behalf Of Jonathan > Rosenberg > Sent: Friday, January 04, 2002 4:47 PM > To: sip@ietf.org; sip-implementors@cs.columbia.edu; mmusic@ietf.org > Subject: [Sip-implementors] supporting just one codec at a time > > > Folks, > > I've been combing through the sip-implementors and sip lists, looking > for open issues that need resolution, or comments that needed > addressing > in the specification. This is the source of much of my spamming on > sip-implementors.... > > An issue that has arisen time and time and time again, is the > need for > an endpoint to indicate in its SDP that it can do any one of > these three > codecs, but can only do one at a time, that is, it doesn't support > dynamically changing codecs on the fly. Since the question has been > asked 1/2 dozen times on sip-implementors, and concerns both sip and > mmusic, I have cross posted. If the thread takes off we'll > trim it to a > single list. > > The response I gave to people who asked about it, was that > this was what > simcap > (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sd > p-simcap-04.txt) > was for, and to go read that. However, after a discussion > with Flemming, > it appears I misinterpreted that specification. It is merely a > declaration of the codes that an endpoint can support. This > information > would be used in subsequent offer/answer exchanges, so that a UA can > make an offer without having to guess whether it would or wouldn't be > accepted. I was under the false impression that the point of > simcap was > to, in fact, solve this particular problem of one-codec-at-a-time for > the initial exchange. > > So, we are faced with this gap of how to handle this problem. I see a > few solutions: > > 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. > > The offer would list ALL the codecs the UA can do, the > counter-offer is > the subset that the other UA can do, and the answer can reduce it > further to just a few. > > This solution would require us to define this 3-way handshake > somewhere; > that is still being debated as an open issue. Bill has included this > already in manyfolks, partly to solve this problem (or maybe > entirely to > solve this problem). > > 2. Define a backwards compatible usage of simcap to modify the > offer-answer exchange. > > The offer would contain an m line with a single codec choice (in this > particular case where it can do only one a time), but the offer would > include simcap attributes indicating support for other codecs. The > answerer could choose from amongst those codecs in formulating the > answer. So, for example: > > Offer: > > m=audio 8778 RTP/AVP 0 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > > This offer means that the offerer is definitely using PCMU > with someone > that doesn't understand simcap, but is indicating they can also do > codecs 1 and 2 (and each of them with rfc2833). The answerer > could pick > one of those alternate cdsc in the answer: > > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > > We would probably need to define an additional attribute in > the SDP that > indicates that this "simcap effects the m line selection" semantic is > being followed. > > This approach may confused intermediaries that are assuming a > subset of > codecs in the answer. > > 3. Define a sort-of backwards compatible usage of simcap with > offer/answer > > In this model, the offerer lists all codecs they can do in the offer. > They include simcap declarations as well. As with normal > offer/answer, > the answerer has to pick a subset, but they use the simcap > declarations > to help them pick a subset which is an allowed capability. So, in the > example above where the caller can do codecs 0,2,3,4 along > with 76, but > only ONE of 0,2,3,4 at a time, the O/A would look like this: > > OFFER: > > m=audio 8778 RTP/AVP 0 1 2 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > > ANSWER: > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > > If, however, the UAS doesn't understand simcap, its possible that > they'll return an SDP listing all four codecs, and possibly > change them > on the fly. That can be fixed, in general, by another re-invite which > lists only a single codec. This will work, but might cause an > RTT worth > of media to be sent using a codec different from the one the UAC > "loaded" into the DSP. > > 4. Declare that simcap is overkill for this one problem, and define a > single attribute, a=pickone, which says to choose only one of > the codecs > in the m line. > > The "I can do one of N, but only one at a time" problem, > IMHO, the only > capability problem that anyone actually has in real usage. I > will note > that, in fact, this is the only capabilities question ever asked on > sip-implementors. > > A single attribute would easily solve it. If you want to do rfc2833 > along with any one of N other codecs, you could use fid along > with this, > to include an m line with the rfc2833, and then another m > line with the > N codecs and the a=pickone attribute. > > > One way or another, we need to solve this problem. My apologies for > bringing this up so late, but I had thought it was solved (I > thought it > implied approach #3 above).... comments on the various alternatives? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 20:48:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17226 for ; Fri, 4 Jan 2002 20:48:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA13962 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 20:48:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13848; Fri, 4 Jan 2002 20:37:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13819 for ; Fri, 4 Jan 2002 20:37:51 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17164 for ; Fri, 4 Jan 2002 20:37:47 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g051beJ10550; Sat, 5 Jan 2002 02:37:41 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g051bdhO014605; Sat, 5 Jan 2002 03:37:40 +0200 (EET) Message-ID: <3C3658ED.CF9E8190@lmf.ericsson.se> Date: Sat, 05 Jan 2002 03:37:49 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, John.Hearty@Level3.com Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C354C13.5D1E4DB5@lmf.ericsson.se> <3C35E91E.5050703@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Also, if the failure in the SIP nodes which caused the media failure >>also caused lost of the SIP call state the re-INVITE won't help, since a >>tagged re-INVITE will trigger 481. > >No, the re-invite can also re-establish dialog state in the backup. You >should read http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt >if you have not alraedy. I don't have anything against what you propose in the draft. So, let's continue the discussion based on that, because the issues I have are pretty much the same. Q1: The draft does also, however, say that the re-INVITE may not work for all nodes (eg PSTN gateways), so that's why I don't think it should be general behaviour. Also, there may be some nodes (maybe the media server) which from a functional point of view does not want to send a re-INVITE. For example, if I call a media server from my SIP phone, and the media server detects a media failure, it may not make such sense for it to generate a re-INVITE, which may end up in my other phone... Q2: Chapter 5 says that the re-INVITE must arrive at UA3, ie the backup, since UA2 generated ICMP. However, shouldn't the first re-INVITE be sent by UA1 to UA2 (where the initial INVITE was sent) in any case, in case the media failure was temporary, or UA2 did a quick reboot? Then, it that fails the UA1 will try UA3 etc. Also, if UA2 recovers by itself, and UA1 has contacted UA3 there is a chance that UA2 will start sending media again, which may get messed up with the media from UA3. UA2 may even detect a media failure itself (eg if new ports were allocated by UA1 for UA3), so it may generate a re-INVITE. AND, that re-INVITE may not even reach UA1 - at least not if it's routed according to Chapter 5. Q3: Also, the draft doesn't say anything about the case where BOTH nodes detect the media failure. Assume that both UA1 and UA2 detects the media failure. The re-INVITE sent by UA1 may end up at UA3, and the re-INVITE sent by UA2 may end up at UA4, in which case things may get messy. One of my phones may send the re-INVITE, and suddenly my other phone starts ringing... or something like that... Q4: About the "server group ID": First, if it's only used only in the To tag, will it work if the CALLED party generates the re-INVITE? Shouldn't the ID also be in the From tag, so that the re-INVITE works in both directions of the call? Also, does an empty ID value mean that no backup node exist? I also think we should investigate if the "server group ID" you propose affects issues like REFER, 3pcc etc. I am not saying it does affect, but IF... :) Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 4 22:21:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18808 for ; Fri, 4 Jan 2002 22:21:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA16429 for sip-archive@odin.ietf.org; Fri, 4 Jan 2002 22:21:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15784; Fri, 4 Jan 2002 21:55:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15630 for ; Fri, 4 Jan 2002 21:54:57 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18623; Fri, 4 Jan 2002 21:54:53 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g052sNE04462; Fri, 4 Jan 2002 21:54:23 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g052sLA13381; Fri, 4 Jan 2002 21:54:22 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 21:52:45 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102ADD0@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Jonathan Rosenberg'" , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Date: Fri, 4 Jan 2002 21:52:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19594.14C2BE50" Subject: [Sip] RE: [MMUSIC] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19594.14C2BE50 Content-Type: text/plain; charset="iso-8859-1" a=pickone corresponds to the Megaco ReserveValue attribute, so it fits our model nicely. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, January 04, 2002 4:47 PM To: sip@ietf.org; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: [MMUSIC] supporting just one codec at a time Folks, I've been combing through the sip-implementors and sip lists, looking for open issues that need resolution, or comments that needed addressing in the specification. This is the source of much of my spamming on sip-implementors.... An issue that has arisen time and time and time again, is the need for an endpoint to indicate in its SDP that it can do any one of these three codecs, but can only do one at a time, that is, it doesn't support dynamically changing codecs on the fly. Since the question has been asked 1/2 dozen times on sip-implementors, and concerns both sip and mmusic, I have cross posted. If the thread takes off we'll trim it to a single list. The response I gave to people who asked about it, was that this was what simcap (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx t) was for, and to go read that. However, after a discussion with Flemming, it appears I misinterpreted that specification. It is merely a declaration of the codes that an endpoint can support. This information would be used in subsequent offer/answer exchanges, so that a UA can make an offer without having to guess whether it would or wouldn't be accepted. I was under the false impression that the point of simcap was to, in fact, solve this particular problem of one-codec-at-a-time for the initial exchange. So, we are faced with this gap of how to handle this problem. I see a few solutions: 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. The offer would list ALL the codecs the UA can do, the counter-offer is the subset that the other UA can do, and the answer can reduce it further to just a few. This solution would require us to define this 3-way handshake somewhere; that is still being debated as an open issue. Bill has included this already in manyfolks, partly to solve this problem (or maybe entirely to solve this problem). 2. Define a backwards compatible usage of simcap to modify the offer-answer exchange. The offer would contain an m line with a single codec choice (in this particular case where it can do only one a time), but the offer would include simcap attributes indicating support for other codecs. The answerer could choose from amongst those codecs in formulating the answer. So, for example: Offer: m=audio 8778 RTP/AVP 0 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 This offer means that the offerer is definitely using PCMU with someone that doesn't understand simcap, but is indicating they can also do codecs 1 and 2 (and each of them with rfc2833). The answerer could pick one of those alternate cdsc in the answer: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event We would probably need to define an additional attribute in the SDP that indicates that this "simcap effects the m line selection" semantic is being followed. This approach may confused intermediaries that are assuming a subset of codecs in the answer. 3. Define a sort-of backwards compatible usage of simcap with offer/answer In this model, the offerer lists all codecs they can do in the offer. They include simcap declarations as well. As with normal offer/answer, the answerer has to pick a subset, but they use the simcap declarations to help them pick a subset which is an allowed capability. So, in the example above where the caller can do codecs 0,2,3,4 along with 76, but only ONE of 0,2,3,4 at a time, the O/A would look like this: OFFER: m=audio 8778 RTP/AVP 0 1 2 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 ANSWER: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event If, however, the UAS doesn't understand simcap, its possible that they'll return an SDP listing all four codecs, and possibly change them on the fly. That can be fixed, in general, by another re-invite which lists only a single codec. This will work, but might cause an RTT worth of media to be sent using a codec different from the one the UAC "loaded" into the DSP. 4. Declare that simcap is overkill for this one problem, and define a single attribute, a=pickone, which says to choose only one of the codecs in the m line. The "I can do one of N, but only one at a time" problem, IMHO, the only capability problem that anyone actually has in real usage. I will note that, in fact, this is the only capabilities question ever asked on sip-implementors. A single attribute would easily solve it. If you want to do rfc2833 along with any one of N other codecs, you could use fid along with this, to include an m line with the rfc2833, and then another m line with the N codecs and the a=pickone attribute. One way or another, we need to solve this problem. My apologies for bringing this up so late, but I had thought it was solved (I thought it implied approach #3 above).... comments on the various alternatives? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01C19594.14C2BE50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] supporting just one codec at a time

a=3Dpickone corresponds to the Megaco ReserveValue = attribute, so it fits our model nicely.

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, January 04, 2002 4:47 PM
To: sip@ietf.org; sip-implementors@cs.columbia.edu; = mmusic@ietf.org
Subject: [MMUSIC] supporting just one codec at a = time


Folks,

I've been combing through the sip-implementors and = sip lists, looking
for open issues that need resolution, or comments = that needed addressing
in the specification. This is the source of much of = my spamming on
sip-implementors....

An issue that has arisen time and time and time = again, is the need for
an endpoint to indicate in its SDP that it can do = any one of these three
codecs, but can only do one at a time, that is, it = doesn't support
dynamically changing codecs on the fly. Since the = question has been
asked 1/2 dozen times on sip-implementors, and = concerns both sip and
mmusic, I have cross posted. If the thread takes off = we'll trim it to a
single list.

The response I gave to people who asked about it, was = that this was what
simcap
(http://www.ietf.org/internet-drafts/draft-andreasen-mm= usic-sdp-simcap-04.txt)
was for, and to go read that. However, after a = discussion with Flemming,
it appears I misinterpreted that specification. It = is merely a
declaration of the codes that an endpoint can = support. This information
would be used in subsequent offer/answer exchanges, = so that a UA can
make an offer without having to guess whether it = would or wouldn't be
accepted. I was under the false impression that the = point of simcap was
to, in fact, solve this particular problem of = one-codec-at-a-time for
the initial exchange.

So, we are faced with this gap of how to handle this = problem. I see a
few solutions:

1. Use a three-way handshake in SIP, using = offer/counter-offer/answer.

The offer would list ALL the codecs the UA can do, = the counter-offer is
the subset that the other UA can do, and the answer = can reduce it
further to just a few.

This solution would require us to define this 3-way = handshake somewhere;
that is still being debated as an open issue. Bill = has included this
already in manyfolks, partly to solve this problem = (or maybe entirely to
solve this problem).

2. Define a backwards compatible usage of simcap to = modify the
offer-answer exchange.

The offer would contain an m line with a single codec = choice (in this
particular case where it can do only one a time), = but the offer would
include simcap attributes indicating support for = other codecs. The
answerer could choose from amongst those codecs in = formulating the
answer. So, for example:

Offer:

m=3Daudio 8778 RTP/AVP 0 76
a=3Drtpmap:76 telephone-event
a=3Dsqn:0
a=3Dcdsc: 1 audio RTP/AVP 0 76
a=3Dcdsc: 3 audio RTP/AVP 1 76
a=3Dcdsc: 5 audio RTP/AVP 2 76

This offer means that the offerer is definitely using = PCMU with someone
that doesn't understand simcap, but is indicating = they can also do
codecs 1 and 2 (and each of them with rfc2833). The = answerer could pick
one of those alternate cdsc in the answer:

m=3Daudio 7554 RTP/AVP 1 76
a=3Drtpmap:76 telephone-event


We would probably need to define an additional = attribute in the SDP that
indicates that this "simcap effects the m line = selection" semantic is
being followed.

This approach may confused intermediaries that are = assuming a subset of
codecs in the answer.

3. Define a sort-of backwards compatible usage of = simcap with offer/answer

In this model, the offerer lists all codecs they can = do in the offer.
They include simcap declarations as well. As with = normal offer/answer,
the answerer has to pick a subset, but they use the = simcap declarations
to help them pick a subset which is an allowed = capability. So, in the
example above where the caller can do codecs 0,2,3,4 = along with 76, but
only ONE of 0,2,3,4 at a time, the O/A would look = like this:

OFFER:

m=3Daudio 8778 RTP/AVP 0 1 2 76
a=3Drtpmap:76 telephone-event
a=3Dsqn:0
a=3Dcdsc: 1 audio RTP/AVP 0 76
a=3Dcdsc: 3 audio RTP/AVP 1 76
a=3Dcdsc: 5 audio RTP/AVP 2 76

ANSWER:
m=3Daudio 7554 RTP/AVP 1 76
a=3Drtpmap:76 telephone-event


If, however, the UAS doesn't understand simcap, its = possible that
they'll return an SDP listing all four codecs, and = possibly change them
on the fly. That can be fixed, in general, by = another re-invite which
lists only a single codec. This will work, but might = cause an RTT worth
of media to be sent using a codec different from the = one the UAC
"loaded" into the DSP.

4. Declare that simcap is overkill for this one = problem, and define a
single attribute, a=3Dpickone, which says to choose = only one of the codecs
in the m line.

The "I can do one of N, but only one at a = time" problem, IMHO, the only
capability problem that anyone actually has in real = usage. I will note
that, in fact, this is the only capabilities = question ever asked on
sip-implementors.

A single attribute would easily solve it. If you want = to do rfc2833
along with any one of N other codecs, you could use = fid along with this,
to include an m line with the rfc2833, and then = another m line with the
N codecs and the a=3Dpickone attribute.


One way or another, we need to solve this problem. My = apologies for
bringing this up so late, but I had thought it was = solved (I thought it
implied approach #3 above).... comments on the = various alternatives?

-Jonathan R.
--
Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
dynamicsoft        &nbs= p;           &nbs= p;        East Hanover, NJ = 07936
jdrosen@dynamicsoft.com      &nbs= p;          FAX: (973) = 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

------_=_NextPart_001_01C19594.14C2BE50-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jan 5 02:24:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01899 for ; Sat, 5 Jan 2002 02:24:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01221 for sip-archive@odin.ietf.org; Sat, 5 Jan 2002 02:24:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00373; Sat, 5 Jan 2002 01:54:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00339 for ; Sat, 5 Jan 2002 01:54:25 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23585 for ; Sat, 5 Jan 2002 01:54:23 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g056sKVZ007514; Sat, 5 Jan 2002 01:54:20 -0500 (EST) Message-ID: <3C36A2FF.5030903@dynamicsoft.com> Date: Sat, 05 Jan 2002 01:53:51 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Sparks CC: "'Dean Willis'" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] re: refer-to header Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert Sparks wrote: > inline > > >>-----Original Message----- >>From: Dean Willis [mailto:dean.willis@softarmor.com] >>Sent: Sunday, December 02, 2001 4:48 PM >>To: Robert Sparks; 'Rohan Mahy'; sip@ietf.org >>Subject: Re: [Sip] re: refer-to header >> >> >>How does one distinguish an HTTP URL that enters a sex site >>from one that >>retrieves info on a Disney character? I recall that there was some >>excitement a few years ago when http://www.bambi.com/ >>retrieved information >>on "wild life" not usually considered suitable for children . . . >> >>In short, the URL is just an entry point. How that entry >>point responds is >>up to the application behind it. This is not a standardizable >>thing. The >>application MAY base its response on the parametrs of the >>request as well as >>on the body of the request. >> >>In the case posed by Robert, my business card might say: >> >>Voice: sip:dean.willis@softarmor.com >>Quake: sip:dw@quakewar.org >> >>Or, it might say: >> >>Voice: sip:dean.willis@softarmor.com >>Quake: sip:dean.willis@softarmor.com >> > > If you do this and you put these on a web page, not > a business card, how does your web browser know which > application to launch to generate the associated INVITE? We are back to one of the big sipping questions, I believe. How do we construct URIs to explicitly invoke services, without standardizing the services? The answers remain the same. If the URI is handed out (i.e., its on a business card), thats when things are best. I can pick whatever URL I like to be the URL to invoke Quake with. Presumably, a user would type this URL into their quake app, and things work. Should they type it into their voip-only SIP phone, they get back a 488 that tells them this is for quake only. The REFER issue is harder. If A is in a call with B, and wants to REFER C to B in order to have them play quake, now were are in a situation where A needs to know the URL to use at A to invoke a particular service. This is a hard, hard problem. I had, in the past, proposed including these URLS in INVITE/200, for the particular case of conferencing: INVITE sip:B SIP/2.0 To-Join: sip:asd988878a9sd0as0d-llkku88asd9@1.2.3.4 Dave Oran asked what URL to use for "blow up my phone", and now we are asked for the URL for "play quake". The variations are infinite. When a URL is not handed out, and must be constructed, we are talking about the old service invocation problem.... I have some ideas on it, but they are not gelled enough for a post. -Jonathan R. >>----- Original Message ----- >>From: "Robert Sparks" >>To: "'Rohan Mahy'" ; >>Sent: Sunday, December 02, 2001 4:09 PM >>Subject: RE: [Sip] re: refer-to header >> >> >> >>>Casting it back to what I put on a business card/web page, >>>how would I distinguish the URL used to enter a quake game >>>with me from the one used to enter a chess game? >>> >>>RjS >>> >>> >>>>-----Original Message----- >>>>From: Rohan Mahy [mailto:rohan@cisco.com] >>>>Sent: Sunday, December 02, 2001 11:51 AM >>>>To: sip@ietf.org >>>>Subject: [Sip] re: refer-to header >>>> >>>> >>>>Hi, >>>> >>>>I think the "right way" to distingish a "voice" INVITE from a >>>>"game" INVITE >>>>is with the caller preferences extensions. >>>> >>>>for example: >>>> >>>>Refer-To: >>>> >>>> >>>> >>>> >To: "'Hisham Khartabil'" , >>>> >>sip@ietf.org >> >>>> >Subject: RE: [Sip] Refer-To header and method-param >>>> >From: Robert Sparks >>>> >Date: Thu, 29 Nov 2001 12:25:57 -0500 >>>> >List-Id: Session Initiation Protocol >>>> >Sender: sip-admin@ietf.org > -----Original Message----- >>>> >> From: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] >>>> >> Sent: Thursday, November 29, 2001 3:38 AM >>>> >> To: sip@ietf.org >>>> >> Subject: [Sip] Refer-To header and method-param >>>> >> >>>> >> >>>> >> Hi, >>>> >> >>>> >> Section 3.5.1 of draft-ietf-sip-refer-02 states: >>>> >> >>>> >> "The resource identified by the Refer-To: URL is contacted >>>> >> using the >>>> >> normal mechanisms for that URL type. For example, if >>>>the URL is a >>>> >> SIP INVITE URL, the UA would issue a new INVITE using >>>>all of the >>>> >> normal rules for sending an INVITE defined in [1]." >>>> >> >>>> >> My question is: How can I determine is the URL is indeed an >>>> >> INVITE URL? What >>>> >> does an "INVITE URL" mean? >>>> >> >>>> >> The only thing I can relate to this is the method-param >>>>in a SIP URL. >>>> >Which is exactly the thing. INVITE is the default value of >>>>that method >>>> >parameter. so sip:foo@bar.com and >>>>sip:foo@bar.com;method=INVITE are INVITE >>>> >URIs. sip:foo@bar.com;method=SUBSCRIBE is a SUBSCRIBE URI > >>>> >> The other question is: If a UAC has the capabilities to REFER >>>> >> someone to a >>>> >> voice session as well as some other session like a Game >>>> >> session. How does it >>>> >> tell the referee what type of INVITE it is. >>>> >> >>>> >> E.g. >>>> >> >>>> >> - A is in a voice session with B >>>> >> - A is in a game session with C >>>> >> - A wants to refer D to join the voice with B and game with >>>> >> C. How would the >>>> >> Refer-To header differ in that scenario? This is a good >>>>question, but its >>>> >not REFER specific. To put it another way, suppose you want >>>>to put a URI that >>>> >someone can use to join your game on a business card or >>>> >on a web page. What does it look like? I've heard a number >>>>of possible >>>> >answers for this >>>> >(and I don't claim this is an exhaustive list) 1) The game >>>>URI looks exactly >>>> >like the voice URI, but you >>>> > use different clients to play games and have voice >>>> > conversations, so the intent is inferred from which >>>> > client you handed the URI too. This has tons of >>>>problems, starting >>>> >with the assumption >>>> > of different clients. 2) The URIs look exactly the >>>>same, and agents >>>> >always include >>>> > every kind of session they support in every offer. >>>>Think of video vs >>>> >audio for a minute. How do you know from >>>> > a SIP URI on a business card that someone supports both? >>>> > The discussion I've heard to date indicates that >>>> >>you don't - >> >>>> > you just include a video m= line if you want to use it and >>>> > if the other side supports it, great! You could take the >>>> > same approach with game streams. The downside of >>>> >>this is that >> >>>> > D above may end up in both a voice and game session (think >>>> > voice and video if you think that's bad) with C. >>>> >>Now if D is >> >>>> > joining an existing dialog at C (which is managing only a >>>> > game session), C can just decline the voice part of >>>>the offer. The >>>> >downside with this approach is having to include an offer >>>> > for everything you support - resource acquisition >>>> >>at the client >> >>>> > may be prohibitive, and the messaging can get huge. What if >>>> > you support 30 different games? Are those games only >>>>distinguished >>>> > by SDP? Do you have 30 sets of m= lines in your >>>> >>offer matching >> >>>> > them? 3) The URIs differ by some parameter, header, or >>>>body content. >>>> > This path has the most promise, but there needs to be >>>> > much discussion about what the difference is. The examples >>>> > of games sessions we've seen before use INVITEs that differ >>>> > only in their SDP - do we include SDP or some subset of it >>>> > in the URI? That way is filled with security and interop >>>> > peril. >>>> > >>>> >4) You just have a different URI for games, video and >>>>voice. This is a >>>> >workaround - not a solution. >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the >>>> >>application of sip >> >>>_______________________________________________ >>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >>> >>> > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jan 5 02:43:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02085 for ; Sat, 5 Jan 2002 02:43:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA01972 for sip-archive@odin.ietf.org; Sat, 5 Jan 2002 02:43:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01284; Sat, 5 Jan 2002 02:24:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01239 for ; Sat, 5 Jan 2002 02:24:15 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01911 for ; Sat, 5 Jan 2002 02:24:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g057OCVZ007525; Sat, 5 Jan 2002 02:24:12 -0500 (EST) Message-ID: <3C36A9FD.8080203@dynamicsoft.com> Date: Sat, 05 Jan 2002 02:23:41 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: sip@ietf.org Subject: Re: [Sip] bis-05: use of 100 Trying Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > Based on the CANCEL thread that is going on, I was trying to sort out the > usage that is currently mandated for generating 100 Trying, which is > different from bis-04. > > For INVITE transactions, > > - stateless proxies never generate it (16.9). It must pass it on no > matter what request it relates to (section 16.9); > > - for all other servers: figure 7 (page 95) and the text in 17.2.1 > cover this. The text says MAY generate a 100 unless... The figure implies a > MUST generate 100. I believe this thread led to the conclusion that the text was correct, and that an additional response code by the UAS instead of 100, in order to indicate end-to-end connectivity, was not needed in and of itself. However, you are correct that Figure 7 is inconsistent with the text in that the figure does seem to imply that 100 is always sent. I will correct that. > For non-INVITE transactions, > > - stateless proxies never generate it (16.9). It must pass it on no > matter what request it relates to (section 16.9); > > - for all other servers: figure 8 (page 105) and the text in 17.2.2 > cover this. There is no text covering the generation of any provisional > response, not even 100 Trying. However figure 8 indicates that the TU may > generate 1xx responses, and that the server process will then pass them on. This is no different from INVITE transactions. > > Does this mean that a TU in a proxy can independently generate 1xx responses > (including 100), or is it an attempt to represent that if a proxy receives a > 1xx response, it will pass it on through the TU and therefore the server > side will generate it? The TU behavior in the case of a proxy is specified in a separate section. I believe it is clear in that section that a proxy passes on all non-100 provisional responses, independent of the method. However, section 16 is indeed silent on whether a proxy can generate its own non-100 provisional responses for any type of transaction. I believe it cannot, but a physical element certainly can do that, by effectively proxying the request to an internal virtual UAS which generates the provisional response. In that case, the provisional response would have tags and record-routes, and establish an early dialog, effectively with the proxy itself (or, more correctly, with the virtual uas co-resident with it). Text is probably needed to clarify that. > > I am unsure whether 100 Trying should be permitted or barred in the above > case. Currently the balance of the text would imply it is precludes for > non-INVITE which would appear to me to be fine. I think it is probably bad, since it will cause very large delays in response retransmissions in the event of a loss of the response, since request retransmissions are needed to retrigger it. This probably belongs in Section 8, on general uas behavior. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jan 5 03:28:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02542 for ; Sat, 5 Jan 2002 03:28:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA03191 for sip-archive@odin.ietf.org; Sat, 5 Jan 2002 03:28:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02914; Sat, 5 Jan 2002 03:14:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02891 for ; Sat, 5 Jan 2002 03:14:04 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02295 for ; Sat, 5 Jan 2002 03:14:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g058E1VZ007531; Sat, 5 Jan 2002 03:14:01 -0500 (EST) Message-ID: <3C36B5AB.2070304@dynamicsoft.com> Date: Sat, 05 Jan 2002 03:13:31 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Terry L Anderson CC: SIP Mailing List Subject: Re: [Sip] Some comments on rfc2543bis-05 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for your comments. Responses inline. Terry L Anderson wrote: > Some comments on rfc2543bis-05. Most are minor editorial issues (I > believe). Perhaps, some have been discuss earlier but I could not find > them. > > Issue 1: Section 6 Definitions > It might be nice to define "Request" and "Response" here. "Message" > appears to be used occasionally and I believe means either Request or > Response but maybe "Message" should also be defined. And 12.2 defines > "Refresh Request". It would be nice to have it included here as well, > for convenient reference. Will do. Thanks. > > Issue 2: Section 8.2.3.2 Require > I just want to confirm that the intention is that even an ACK, BYE or > CANCEL containing a Require header with option tags that the recipient > does not support should be rejected with a 420 response. BYE, most definitely. ACK can never be responded to. I would probably argue that ACK should never contain a Require or Proxy-Require that wasn't in the request, and furthermore that ACK for 420 never contain Require or Proxy-Require with option tags not listed in Supported in the 420. The result of these two requirements is that you will never get an ACK you need to reject. The alternative would be to disallow REquire in ACK altogether. Whilst I wouldn't object to that too much for non-2xx, I think it could easily be needed in ACK for 2xx, and am reluctant to disallow it. So, to keep it simple, I think its easiest to disallow Require or Proxy-Require in ACK for non-2xx, and allow in in 2xx only for values also present in the request. This text would go in section 8.2.3.2. As for CANCEL, it will NEVER be useful, since responses are hop by hop, and you can never resubmit a CANCEL if you are wrong. Therefore, I think we should forbid it in CANCEL. Objections? > I would assume > that Require would most often be used in INVITE or REGISTER, but is > allowed in ACK, BYE and CANCEL. Should we refuse to BYE or CANCEL the > call? I guess this requires the sender to resend without the option tag > in Require or the call will not be cleaned up. Correct. > Issue 3: Section 23 Header Fields: Table 3 > Require has a 'g' in the where column and To has a 'gc(1)'. I believe > that the 'g's are left over from bis-04; the meaning for this and the > other instances have been removed in bis-05. Good catch, thanks. > > Issue 4: Section 8.2.7 > The last paragraph states: "The same tag MUST be used for all responses > to that request, both provisional and final". But since the tag is used > as part of the dialog ID, isn't it required to be used in subsequent > requests in the dialog? This is probably clear from statements > elsewhere, but since this sentence could be read as implying the > lifetime of the tag it might be clearer if it read something like "... > all responses to that request, both provisional and final (and any later > requests in the same dialog)." The section at hand is on generation of responses, so it only makes sense to have normative behavior for response generation in here. So, although it is required to be used in subsequent requests in the dialog, that is also clearly described elsewhere. Thus, I think the text is OK as it stands. > > Issue 5: Section 9.2 > Related to my issue 2 above. The last paragraph of 9.2 states that "The > CANCEL request itself is answered with a 200 (OK) in either case." This > might be read to mean in "every" case, but might the response be 420 if > the CANCEL contained an unsupported option tag in Require? Based on the above, no. However, CANCEL itself should undergo the general uas processing rules first, which would have handled the case of generation of 420. Only once that processing is passed, is the cancel specific processing here applied. This needs to be stated. I will add that. > > Issue 6: Section 15.1.2 > Similar to issue 5, this section states that "The UAS core MUST generate > a 2xx response to the BYE", but should it rather generate a 420 if the > BYE contained an unsupported option tag in Require? As above, it needs to follow the general UAS processing first. We'll add a sentence. > > Issue 7: Section 16.1, 16.6 and 8.2.7 > I am trying to understand if there are cases where a final, non-200 > response received by UAC might contain NO To-tag. Section 8.2.7 appears > to require a UAS to add a To-tag to ALL responses. Section 16.6 appears > to states that a proxy MUST NOT insert a To-tag into a forwarded > response that does not have one, but from 8.2.7, it must always have one > (unless it is received from a non-complying UAS). I assume that the > proxy is NOT permitted to remove the tag. Section 16.1 requires that a > proxy that is responding directly (generates a response rather than > forwards one) must behave as a UAS including section 8.2 and so > apparently must add a To-tag. So it would seem that a response received > by the UAC will always have one, except for the case there the UAS in > non-complying. Am I missing a case? (We have seen 4xx's from proxies > with no To-tag and am trying to determine if this should be expected in > some cases). The only case is going to be older rfc2543 proxies, which may not insert them. Its not clear from rfc2543 whether proxies need to insert them when they generate their own response. Another case is a direct UAC to UAS request; there, the response need not have a tag according to rfc2543. However, I think rfc2543 is pretty clear that UAS inserts tags into all responses if there is more than one via. > > Issue 8: Section 15 > If I understand this section, a caller should use a BYE to terminate an > early dialog (rather than a CANCEL) but must not use a CANCEL until some > response is received. Yes. > Since UAS must add a To-tag to all responses, any > provisional response other than 100, received by UAC should contain a > To-tag and hence establish a dialog. Yes. > So it appears that UAC will only > use CANCEL between receipt of 100 (if received) and some other 1xx. Is > this correct? No. BYE is used to terminate a specific early dialog. If, however, the caller wants to end the call, it wants to terminate all dialogs, and so would send a CANCEL. > Perhaps, stating that here would make it clearer. Definitely. I see how you would interpret the text this way. > > Issue 9: Early media > If a proxy forks an INVITE containing SDP, the UAC may receive > provisional responses from more than one UAS, establishing more than one > dialog. If more than one of these contains SDP this would appear to > establish more than one media stream that might be used to send early > media to the UAC on the same port. For example, more than one UAS may > be sending ringback tones in a media stream and one or more may contain > a special information tone or voice message. The RTP packets can be > distinguished by the source addresses in the headers, but is it stated > anywhere what the expected behavior of the UAC is? Should it mix these > and play all of these to the calling party? If not, how can it choose > which to present to the calling party? Or is early media outside the > scope of 2543bis? At the moment, outside the scope of bis. Its documented in draft-rosenberg-sip-early-media, which discusses the "legacy" implementation you describe above. Note that this document is not stable yet. The issue you raise above about disambiguating media from multiple sources is one of the problems that draft tries to address. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jan 5 09:46:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04778 for ; Sat, 5 Jan 2002 09:46:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA12314 for sip-archive@odin.ietf.org; Sat, 5 Jan 2002 09:46:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11839; Sat, 5 Jan 2002 09:28:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11808 for ; Sat, 5 Jan 2002 09:28:21 -0500 (EST) Received: from blaze.hcltech.com (IDENT:root@[203.199.199.225]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04660 for ; Sat, 5 Jan 2002 09:27:39 -0500 (EST) Received: from prakashmlu.netlab.hcltech.com ([192.168.201.86]) by blaze.hcltech.com (8.9.3/8.9.3) with ESMTP id TAA31377; Sat, 5 Jan 2002 19:57:54 +0530 Message-Id: <4.3.2.7.1.20020105193557.00bedef0@192.168.201.1> X-Sender: uprakash@192.168.201.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 05 Jan 2002 19:59:51 -0800 To: sip-implementors@cs.columbia.edu, sip@ietf.org From: Ulrich Prakash Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] Do we(Registrar or UA) need to listen for any other multicast other than sip.mcast.net(224.0.1.75) ? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I want to know, if our Registrar or UA, need to listen for any other multicast IP address, other than sip.mcast.net(224.0.1.75). From the link, http://www.iana.org/assignments/multicast-addresses , I find that only 224.0.1.75 is allocated to sip. If so, how are those Multicast IP addresses(values) chosen,when the UA or Registrar is to be online on the Internet? And when do we really need more than one multicast group? Any replies,suggestions,pointers in this regard would be helpful. Thanks, Prakash. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jan 5 15:32:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07098 for ; Sat, 5 Jan 2002 15:32:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20305 for sip-archive@odin.ietf.org; Sat, 5 Jan 2002 15:32:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19688; Sat, 5 Jan 2002 15:14:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19658 for ; Sat, 5 Jan 2002 15:14:35 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06973 for ; Sat, 5 Jan 2002 15:14:33 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g05KE5F01024 for ; Sat, 5 Jan 2002 12:14:05 -0800 (PST) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABT01611; Sat, 5 Jan 2002 12:14:13 -0800 (PST) From: "Cullen Jennings" To: Date: Sat, 5 Jan 2002 12:22:23 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Sip] Comments on draft-schulzrinne-sip-reason-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Do we really need the reason code or is the cause code enough? Do we need to know the identify (URI or something) of the person who caused the generation of the header? For example, If a proxy sent an forked an invite with an URI of sip:cullen@cisco.com and got back a 600 then decided to cancel the other branches, I think it might be useful to have the "sip:cullen@cisco.com" in the reason header. Embedding Q.850 stuff into the SIP protocols seems like a bad idea. If we need to add a few new SIP response codes to be able to create a richer ISDN to SIP mapping that is fine but I'm not sure I see why Q.850 codes are needed. I assume that a message can only have one reason header. Would a generic solution to the call history problem also be able to meet the requirements that this solves? _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jan 5 20:26:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08808 for ; Sat, 5 Jan 2002 20:26:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA26333 for sip-archive@odin.ietf.org; Sat, 5 Jan 2002 20:26:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26179; Sat, 5 Jan 2002 20:08:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA26150 for ; Sat, 5 Jan 2002 20:08:51 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08715 for ; Sat, 5 Jan 2002 20:08:48 -0500 (EST) Received: from metroliner.cs.columbia.edu (IDENT:root@metroliner.cs.columbia.edu [128.59.19.252]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA06340; Sat, 5 Jan 2002 20:08:40 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by metroliner.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id g0618dd06894; Sat, 5 Jan 2002 20:08:40 -0500 Message-ID: <3C37A481.73A11227@cs.columbia.edu> Date: Sat, 05 Jan 2002 20:12:33 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org Subject: Re: [Sip] Comments on draft-schulzrinne-sip-reason-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for your feedback. Cullen Jennings wrote: > > Do we really need the reason code or is the cause code enough? The idea is to have one code that an implementation can look at without having to know protocol details, e.g., about ISUP. > > Do we need to know the identify (URI or something) of the person who caused > the generation of the header? For example, If a proxy sent an forked an > invite with an URI of sip:cullen@cisco.com and got back a 600 then decided > to cancel the other branches, I think it might be useful to have the > "sip:cullen@cisco.com" in the reason header. Interesting idea, but I'm a bit concerned about having this be uniquely defined. In most cases, this would be the same as the original request URI in any event. > > Embedding Q.850 stuff into the SIP protocols seems like a bad idea. If we > need to add a few new SIP response codes to be able to create a richer ISDN > to SIP mapping that is fine but I'm not sure I see why Q.850 codes are > needed. This is effectively just carrying the information around. Since there's the reason code, the receiver doesn't have to interpret it, but could. This is similar to what happens when you get back an SMTP failure indication that was actually caused by some X.400 mail system. The SMTP message contains an indication of the original error message so that an X.400 expert can look at it and interpret it. Maybe it would be appropriate to say that the protocol can carry any numeric "foreign" error code. The problem with translation is that while this might work for Q.850, the next protocol that comes along will have some other set, so the translation will often be many-to-one, thus losing information. (For example, one could imagine having to carry back H.323 or Avvid codes.) I'm not wedded to the idea of carrying around "foreign" error codes, so I would welcome other feedback. > > I assume that a message can only have one reason header. Yes; I will add a note to this effect. > > Would a generic solution to the call history problem also be able to meet > the requirements that this solves? Possibly. Maybe once a concrete proposal has been worked out, we'll know. > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 6 07:27:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22969 for ; Sun, 6 Jan 2002 07:27:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA20668 for sip-archive@odin.ietf.org; Sun, 6 Jan 2002 07:28:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20506; Sun, 6 Jan 2002 07:14:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20475 for ; Sun, 6 Jan 2002 07:14:28 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22879 for ; Sun, 6 Jan 2002 07:14:24 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g06CEGK16452; Sun, 6 Jan 2002 13:14:16 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g06CEFhO000842; Sun, 6 Jan 2002 14:14:15 +0200 (EET) Message-ID: <3C383FAE.8EC268FA@lmf.ericsson.se> Date: Sun, 06 Jan 2002 14:14:38 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Comments on draft-schulzrinne-sip-reason-00.txt References: <3C37A481.73A11227@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Embedding Q.850 stuff into the SIP protocols seems like a bad idea. If we >>need to add a few new SIP response codes to be able to create a richer ISDN >>to SIP mapping that is fine but I'm not sure I see why Q.850 codes are >>needed. > >This is effectively just carrying the information around. Since there's >the reason code, the receiver doesn't have to interpret it, but could. >This is similar to what happens when you get back an SMTP failure >indication that was actually caused by some X.400 mail system. The SMTP >message contains an indication of the original error message so that an >X.400 expert can look at it and interpret it. > >Maybe it would be appropriate to say that the protocol can carry any >numeric "foreign" error code. > >The problem with translation is that while this might work for Q.850, >the next protocol that comes along will have some other set, so the >translation will often be many-to-one, thus losing information. (For >example, one could imagine having to carry back H.323 or Avvid codes.) > >I'm not wedded to the idea of carrying around "foreign" error codes, so >I would welcome other feedback. I also wonder if it's really needed. The ISUP/SIP mapping draft defines how SIP reason codes are mapped into Q.850 when received in a RESPONSE message. Couldn't the same mechanism be used to map the SIP reason code when received in a REQUEST message? Of course, the receiver could ignore the cause code and map the reason code according to the ISUP/SIP mapping draft (or according to whatever specification) anyway... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 6 09:36:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23763 for ; Sun, 6 Jan 2002 09:36:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA23814 for sip-archive@odin.ietf.org; Sun, 6 Jan 2002 09:36:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23242; Sun, 6 Jan 2002 09:22:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23211 for ; Sun, 6 Jan 2002 09:22:02 -0500 (EST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23661 for ; Sun, 6 Jan 2002 09:21:56 -0500 (EST) Received: from DOR2 (dial-02 [193.174.152.253]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g06ELuh25831 for ; Sun, 6 Jan 2002 15:21:57 +0100 (MET) Date: Sun, 6 Jan 2002 15:20:26 +0100 From: Dorgham Sisalem X-Mailer: The Bat! (v1.53d) UNREG / CD5BF9353B3B7091 Reply-To: Dorgham Sisalem Organization: GMD Fokus X-Priority: 3 (Normal) Message-ID: <199145588104.20020106152026@fokus.gmd.de> CC: sip@ietf.org Subject: Re[2]: [Sip] MAJOR Open Issue #184: Message size limitations In-Reply-To: <15413.55045.821171.732298@thomasm-u1.cisco.com> References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> <3C33009A.6B232FF9@lmf.ericsson.se> <013501c193c7$656d6e50$01000001@dynamicsoft.com> <3C33F328.462434B8@lmf.ericsson.se> <15412.36246.307190.661368@thomasm-u1.cisco.com> <3C354535.D01C0BDF@lmf.ericsson.se> <15413.55045.821171.732298@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, looking at all the complexity of 499 and UDP to TCP transition I am wondering if fragmentation is really worth the trouble. For the case of signaling I hardly imagine the messages will get big enough so as to worry about congestion due to retransmission (just because a SIP message was fragmented into two or three messages of which all will have to be retransmitted when one is lost should not cause congestion, specially when considering that the signaling traffic will most probably be only a small portion of the overall traffic. If we expect that the SIP signaling messages will get really big so that we need to worry about congestion then I believe something went wrong with the protocol design). What is more worrying naturally is when SIP is used to send messages with large bodies. In this case the sender should refer to TCP directly or divide the body into different messages and and send them in a TCP like fashion (only send a message when the previous one was acknowledged) thereby the SIP loss handling mechanisms would deal with the congestion avoidance. Cheers Friday, January 04, 2002, 5:23:33 PM, you wrote: > Sorry -- perhaps a bit too obscure. The point I'm > making is that an "operator" may in fact be very, > very small so that any supposed site-wide policy > may be inconsequential, and the likelihood of > peering arrangements negligible. SIP needs to work > in cross realm settings large and small equally > well. Therefore we can't hand wave this issue away > by saying that it can be dealt with as a general > issue with peering with well defined peering > points. That is very likely how large operators > will set up their networks, but that does not > scale for lots of very small SIP deployments. > Mike > Christer Holmberg writes: > > > > Hi Mike, > > > > I am not really sure I understood your question, but I assume that you > > meant that you want TCP to be used for the CEO, while others can use > > UDP. Right? > > > > We should remember that the SIP SIGNALLING is only a small part of the > > messages sent during session, so from that point of view I think the > > session with the CEO will be established no matter what transport > > protocol is used, even if some UDP fragments of the INVITE is lost and > > must be re-sent. > > > > The MEDIA, however, will still be transported on UDP (in an IP bearer > > network using RTP), so if there are lots of delay and packet losses in > > the network your CEO isn't going to be too happy anyway - even if he got > > the INVITE in a "nice and reliable" way. > > > > Again, I appologise if I missunderstood your question :) > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > Michael Thomas wrote: > > > > > > Christer Holmberg writes: > > > > > > > > Hi, > > > > > > > > The solution to the problem you describe is - SIP. If an operator has > > > > the problem with UDP that you describe, either in the whole of his > > > > network or between specific SIP nodes, he may configure the nodes to use > > > > TCP (or SCTP, or whatever) instead of UDP. Again, that's one of the good > > > > things of having a transport independent protocol. > > > > > > So what happens when the sprawling operations of > > > softarmor.com and mtcc.com need to put their > > > Very Important CEO's in touch? > > > > > > Mike > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Best regards, Dorgham mailto:sisalem@fokus.gmd.de _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 6 13:06:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25215 for ; Sun, 6 Jan 2002 13:06:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28326 for sip-archive@odin.ietf.org; Sun, 6 Jan 2002 13:07:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27858; Sun, 6 Jan 2002 12:52:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27825 for ; Sun, 6 Jan 2002 12:52:27 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25109 for ; Sun, 6 Jan 2002 12:52:24 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA13061; Sun, 6 Jan 2002 12:52:26 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g06HqKJ1015106; Sun, 6 Jan 2002 12:52:25 -0500 (EST) Message-ID: <3C388ED4.19AB555D@cs.columbia.edu> Date: Sun, 06 Jan 2002 12:52:20 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Dorgham Sisalem CC: sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <17052388D394D411803900508BDFFAF601B370DB@n0214idc1.oss.level3.com> <3C33009A.6B232FF9@lmf.ericsson.se> <013501c193c7$656d6e50$01000001@dynamicsoft.com> <3C33F328.462434B8@lmf.ericsson.se> <15412.36246.307190.661368@thomasm-u1.cisco.com> <3C354535.D01C0BDF@lmf.ericsson.se> <15413.55045.821171.732298@thomasm-u1.cisco.com> <199145588104.20020106152026@fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dorgham Sisalem wrote: > > Hello, > looking at all the complexity of 499 and UDP to TCP transition I am > wondering if fragmentation is really worth the trouble. For the case > of signaling I hardly imagine the messages will get big enough so as > to worry about congestion due to retransmission (just because a SIP I think the congestion aspect deserves an additional sentence or two. Effectively, SIP behaves like TCP with a window size of 1 segment and only time-out based retransmission, i.e., the most conservative operational mode of TCP. Depending on the RTT estimate, the SIP timers will obviously differ, but their growth behavior is also similar. The main problem is that with fragmentation, SIP may fail completely if various NATs and firewalls get in the way. That, in my view, is the bigger issue. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 6 13:27:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25338 for ; Sun, 6 Jan 2002 13:27:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28517 for sip-archive@odin.ietf.org; Sun, 6 Jan 2002 13:27:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28460; Sun, 6 Jan 2002 13:19:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28429 for ; Sun, 6 Jan 2002 13:19:19 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25286 for ; Sun, 6 Jan 2002 13:19:16 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA17325; Sun, 6 Jan 2002 13:19:07 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g06IIpJ1015644; Sun, 6 Jan 2002 13:19:01 -0500 (EST) Message-ID: <3C38950B.CB95B51C@cs.columbia.edu> Date: Sun, 06 Jan 2002 13:18:51 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Comments on draft-schulzrinne-sip-reason-00.txt References: <3C37A481.73A11227@cs.columbia.edu> <3C383FAE.8EC268FA@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > I also wonder if it's really needed. The ISUP/SIP mapping draft defines > how SIP reason codes are mapped into Q.850 when received in a RESPONSE > message. Couldn't the same mechanism be used to map the SIP reason code > when received in a REQUEST message? Is the mapping one-to-one? One potential problem is that the reason codes in the Reason header would each map to several Q.850 codes, thus losing information. > > Of course, the receiver could ignore the cause code and map the reason > code according to the ISUP/SIP mapping draft (or according to whatever > specification) anyway... > Indeed; the cause code is optional, after all. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 6 21:02:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28483 for ; Sun, 6 Jan 2002 21:02:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA08631 for sip-archive@odin.ietf.org; Sun, 6 Jan 2002 21:02:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08036; Sun, 6 Jan 2002 20:40:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA08012 for ; Sun, 6 Jan 2002 20:40:24 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28269 for ; Sun, 6 Jan 2002 20:40:19 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g071dqF18498; Sun, 6 Jan 2002 17:39:52 -0800 (PST) Received: from cisco.com (sjc-vpn2-791.cisco.com [10.21.115.23]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ABT06458; Sun, 6 Jan 2002 17:39:58 -0800 (PST) Message-ID: <3C38FBEB.96DE1980@cisco.com> Date: Sun, 06 Jan 2002 17:37:47 -0800 From: Charles Eckel Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Shail Bhatnagar , Brian Stucker , Scott Orton , "'Kiranmai Pavoori'" , vkg , sip Subject: Re: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! References: <3C20E518.6060003@dynamicsoft.com> <3C223DA8.9D5484AE@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan, We can/will make the necessary modifications to comply with the depreciation, so you have the green light from Cisco. Shail, thanks for clarifying the issue and the necessary fix. Cheers -- Charles Eckel Software Engineer Voice Technology Group, Cisco Systems http://www.cisco.com Shail Bhatnagar wrote: > > Jonathan Rosenberg wrote: > > > > Let me summarize the results so far. > > > > Scott Orton, Vijay Gurbani, Kiranai Pavoori, Brian Stucker all indicated > > it was fine to deprecate absolute times (option A). > > > > Brett Tate says they have deployments with registrars that return > > absolute times, but it would be OK to proceed with option A anway; I > > assume this means that the registrars would need to be revved as soon as > > any of the handsets became bis compliant (since they wouldn't be able to > > handle the absolute tiems). Note that the opposite is true, you don't > > need to rev the handsets if you upgrade the registrar. > > > > Shail indicated that their registrar uses absolute times. Shail - can we > > get more details here? Would there be issues in existing deployments > > that would be seriously affected by this change? I'd really like to do > > option A, since otherwise you need to carry around the code for absolute > > time processing anyway. > > Jonathan, Our proxy/registrar generates 200 response of the form > > SIP/2.0 200 OK > Contact: ;expires=gmt stamp > Contact: ;expires=gmt stamp > This is more of an issue for the clients being used > by existing deployments. If customer X, using our > registrar, changes their client and the client cannot > understand this 200 response, there maybe issues. > This gmt time stamp in 200 responses will probably > not be fixed for next few months in our proxy. > > Charles/Sean you want to add something ?? > > Thanks, > Shail > > > > > Any others? > > > > -Jonathan R. > > > > Brian Stucker wrote: > > > > > Propsal A is the way to go. Do away with absolute times, they cause problems and they're of no real use because all times are relative to the current clock at the processing node anyhow. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Orton, Scott [NGC:B633:EXCH] > > > Sent: Tuesday, December 11, 2001 3:46 PM > > > To: 'Kiranmai Pavoori'; jdrosen; vkg > > > Cc: sip > > > Subject: RE: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! > > > > > > > > > > > > Proposal A is fine. > > > > > > Scott > > > Nortel Networks > > > > > > -----Original Message----- > > > From: Kiranmai Pavoori [ mailto:kiranmai.pavoori@intervoice-brite.com] > > > Sent: Tuesday, December 11, 2001 9:48 AM > > > To: jdrosen; vkg > > > Cc: sip > > > Subject: Re: [Sip] Open Issue #178: Deprecate absolute times absolutely: > > > SPEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! > > > > > > > > > Proposal A resolves lots of synchronization problems seen in my work.. > > > > > > > > > > > > > > >>>>Vijay Gurbani 12/10 12:44 PM >>> > > >>>> > > > Jonathan Rosenberg wrote: > > > > > >>Issue: > > >> > > >>The Expires header and expires param in the Contact header allow for > > >>absolute times expressed in GMT. The problem with using absolute times in > > >>the messages is that they require clock synchronization between the two > > >>elements. > > >> > > > [...] > > > > > >>PROPOSAL A: > > >> * Remove absolute times entirely from the specification > > >> > > >>PROPOSAL B: > > >> * Elements MUST NOT send messages with absolute times in Expires or > > >>;expires, but they MUST be prepared to receive requests with absolute > > >>times in those headers, for backwards compatibility > > >> > > >>If we can do A, we should. So, speak up NOW if you use absolute times!!! > > >> > > > > > > Proposal A is fine. Our registrar sends out delta time in responses to > > > Register requests, for instance. > > > > > > Thanks, > > > > > > - vijay > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 01:16:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02834 for ; Mon, 7 Jan 2002 01:16:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA23780 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 01:16:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15011; Mon, 7 Jan 2002 01:03:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14980 for ; Mon, 7 Jan 2002 01:03:05 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02738 for ; Mon, 7 Jan 2002 01:03:01 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0762uK11740; Mon, 7 Jan 2002 07:02:56 +0100 (MET) Received: from lmf.ericsson.se (lmf00215pc.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0762thO010521; Mon, 7 Jan 2002 08:02:55 +0200 (EET) Message-ID: <3C393A0E.88885141@lmf.ericsson.se> Date: Mon, 07 Jan 2002 08:02:54 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Cullen Jennings , sip@ietf.org Subject: Re: [Sip] Comments on draft-schulzrinne-sip-reason-00.txt References: <3C37A481.73A11227@cs.columbia.edu> <3C383FAE.8EC268FA@lmf.ericsson.se> <3C38950B.CB95B51C@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>I also wonder if it's really needed. The ISUP/SIP mapping draft defines >>how SIP reason codes are mapped into Q.850 when received in a RESPONSE >>message. Couldn't the same mechanism be used to map the SIP reason code >>when received in a REQUEST message? > >Is the mapping one-to-one? One potential problem is that the reason >codes in the Reason header would each map to several Q.850 codes, thus >losing information. I guess that's something we should look into. Otherwise, one could argue that we should allow the reason code to RESPONSE messages too... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 11:06:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18611 for ; Mon, 7 Jan 2002 11:06:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11076 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 11:06:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10291; Mon, 7 Jan 2002 10:46:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10209 for ; Mon, 7 Jan 2002 10:46:03 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17859; Mon, 7 Jan 2002 10:46:01 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g07FjUA14635; Mon, 7 Jan 2002 10:45:31 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g07FjEF22823; Mon, 7 Jan 2002 15:45:15 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 15:44:02 -0000 Message-ID: From: "Mark Watson" To: "Tom-PT Taylor", "'Jonathan Rosenberg'" , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: RE: [Sip] RE: [MMUSIC] supporting just one codec at a time Date: Mon, 7 Jan 2002 15:43:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19792.1E9A4290" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19792.1E9A4290 Content-Type: text/plain; charset="iso-8859-1" Generalising: a=pickn: meaning "pick any 'n' codecs from the list on the m= line, so long as the ones from are included in that n" would allow you to encode things like 'I support G.711 *or* G.726 and I support RFC2833 with either': There are a bunch of other ways to specify general sub-sets of the , for example a list of n-bit bit masks, where n is the size of the fmt list etc. I can imagine cases where a UA supports several compressed codecs, only one at a time, but supports upspeeding to G.711 and RFC2833 with all of them. The offer/counter-offer/answer case is always needed for whenever the UAS does not support any new SDP attribute such as that above. In this case you have the possibility of 1 RTT of lost media, as described below. ...Mark -----Original Message----- From: Taylor, Tom-PT [CAR:B800:EXCH] Sent: 05 January 2002 02:53 To: 'Jonathan Rosenberg'; sip@ietf.org; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: [Sip] RE: [MMUSIC] supporting just one codec at a time a=pickone corresponds to the Megaco ReserveValue attribute, so it fits our model nicely. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, January 04, 2002 4:47 PM To: sip@ietf.org; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: [MMUSIC] supporting just one codec at a time Folks, I've been combing through the sip-implementors and sip lists, looking for open issues that need resolution, or comments that needed addressing in the specification. This is the source of much of my spamming on sip-implementors.... An issue that has arisen time and time and time again, is the need for an endpoint to indicate in its SDP that it can do any one of these three codecs, but can only do one at a time, that is, it doesn't support dynamically changing codecs on the fly. Since the question has been asked 1/2 dozen times on sip-implementors, and concerns both sip and mmusic, I have cross posted. If the thread takes off we'll trim it to a single list. The response I gave to people who asked about it, was that this was what simcap (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx t) was for, and to go read that. However, after a discussion with Flemming, it appears I misinterpreted that specification. It is merely a declaration of the codes that an endpoint can support. This information would be used in subsequent offer/answer exchanges, so that a UA can make an offer without having to guess whether it would or wouldn't be accepted. I was under the false impression that the point of simcap was to, in fact, solve this particular problem of one-codec-at-a-time for the initial exchange. So, we are faced with this gap of how to handle this problem. I see a few solutions: 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. The offer would list ALL the codecs the UA can do, the counter-offer is the subset that the other UA can do, and the answer can reduce it further to just a few. This solution would require us to define this 3-way handshake somewhere; that is still being debated as an open issue. Bill has included this already in manyfolks, partly to solve this problem (or maybe entirely to solve this problem). 2. Define a backwards compatible usage of simcap to modify the offer-answer exchange. The offer would contain an m line with a single codec choice (in this particular case where it can do only one a time), but the offer would include simcap attributes indicating support for other codecs. The answerer could choose from amongst those codecs in formulating the answer. So, for example: Offer: m=audio 8778 RTP/AVP 0 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 This offer means that the offerer is definitely using PCMU with someone that doesn't understand simcap, but is indicating they can also do codecs 1 and 2 (and each of them with rfc2833). The answerer could pick one of those alternate cdsc in the answer: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event We would probably need to define an additional attribute in the SDP that indicates that this "simcap effects the m line selection" semantic is being followed. This approach may confused intermediaries that are assuming a subset of codecs in the answer. 3. Define a sort-of backwards compatible usage of simcap with offer/answer In this model, the offerer lists all codecs they can do in the offer. They include simcap declarations as well. As with normal offer/answer, the answerer has to pick a subset, but they use the simcap declarations to help them pick a subset which is an allowed capability. So, in the example above where the caller can do codecs 0,2,3,4 along with 76, but only ONE of 0,2,3,4 at a time, the O/A would look like this: OFFER: m=audio 8778 RTP/AVP 0 1 2 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 ANSWER: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event If, however, the UAS doesn't understand simcap, its possible that they'll return an SDP listing all four codecs, and possibly change them on the fly. That can be fixed, in general, by another re-invite which lists only a single codec. This will work, but might cause an RTT worth of media to be sent using a codec different from the one the UAC "loaded" into the DSP. 4. Declare that simcap is overkill for this one problem, and define a single attribute, a=pickone, which says to choose only one of the codecs in the m line. The "I can do one of N, but only one at a time" problem, IMHO, the only capability problem that anyone actually has in real usage. I will note that, in fact, this is the only capabilities question ever asked on sip-implementors. A single attribute would easily solve it. If you want to do rfc2833 along with any one of N other codecs, you could use fid along with this, to include an m line with the rfc2833, and then another m line with the N codecs and the a=pickone attribute. One way or another, we need to solve this problem. My apologies for bringing this up so late, but I had thought it was solved (I thought it implied approach #3 above).... comments on the various alternatives? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01C19792.1E9A4290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] RE: [MMUSIC] supporting just one codec at a = time

Generalising:

a=3Dpickn: <n> <fmt list>

meaning "pick any 'n' codecs from the list on = the m=3D line, so long as the ones from <fmt list> are included = in that n" would allow you to encode things like 'I support G.711 = *or* G.726 and I support RFC2833 with either':

There are a bunch of other ways to specify general = sub-sets of the <fmt list>, for example a list of n-bit bit = masks, where n is the size of the fmt list etc.

I can imagine cases where a UA supports several = compressed codecs, only one at a time, but supports upspeeding to G.711 = and RFC2833 with all of them.

The offer/counter-offer/answer case is always needed = for whenever the UAS does not support any new SDP attribute such as = that above. In this case you have the possibility of 1 RTT of lost = media, as described below.

...Mark

-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH]
Sent: 05 January 2002 02:53
To: 'Jonathan Rosenberg'; sip@ietf.org; = sip-implementors@cs.columbia.edu; mmusic@ietf.org
Subject: [Sip] RE: [MMUSIC] supporting just one = codec at a time


a=3Dpickone corresponds to the Megaco ReserveValue = attribute, so it fits our model nicely.
-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, January 04, 2002 4:47 PM
To: sip@ietf.org; sip-implementors@cs.columbia.edu; = mmusic@ietf.org
Subject: [MMUSIC] supporting just one codec at a = time


Folks,
I've been combing through the sip-implementors and = sip lists, looking
for open issues that need resolution, or comments = that needed addressing
in the specification. This is the source of much of = my spamming on
sip-implementors....
An issue that has arisen time and time and time = again, is the need for
an endpoint to indicate in its SDP that it can do = any one of these three
codecs, but can only do one at a time, that is, it = doesn't support
dynamically changing codecs on the fly. Since the = question has been
asked 1/2 dozen times on sip-implementors, and = concerns both sip and
mmusic, I have cross posted. If the thread takes off = we'll trim it to a
single list.
The response I gave to people who asked about it, = was that this was what
simcap
(http://www.ietf.org/internet-drafts/draft-andreasen-mm= usic-sdp-simcap-04.txt)
was for, and to go read that. However, after a = discussion with Flemming,
it appears I misinterpreted that specification. It = is merely a
declaration of the codes that an endpoint can = support. This information
would be used in subsequent offer/answer exchanges, = so that a UA can
make an offer without having to guess whether it = would or wouldn't be
accepted. I was under the false impression that the = point of simcap was
to, in fact, solve this particular problem of = one-codec-at-a-time for
the initial exchange.
So, we are faced with this gap of how to handle this = problem. I see a
few solutions:
1. Use a three-way handshake in SIP, using = offer/counter-offer/answer.
The offer would list ALL the codecs the UA can do, = the counter-offer is
the subset that the other UA can do, and the answer = can reduce it
further to just a few.
This solution would require us to define this 3-way = handshake somewhere;
that is still being debated as an open issue. Bill = has included this
already in manyfolks, partly to solve this problem = (or maybe entirely to
solve this problem).
2. Define a backwards compatible usage of simcap to = modify the
offer-answer exchange.
The offer would contain an m line with a single = codec choice (in this
particular case where it can do only one a time), = but the offer would
include simcap attributes indicating support for = other codecs. The
answerer could choose from amongst those codecs in = formulating the
answer. So, for example:
Offer:
m=3Daudio 8778 RTP/AVP 0 76
a=3Drtpmap:76 telephone-event
a=3Dsqn:0
a=3Dcdsc: 1 audio RTP/AVP 0 76
a=3Dcdsc: 3 audio RTP/AVP 1 76
a=3Dcdsc: 5 audio RTP/AVP 2 76
This offer means that the offerer is definitely = using PCMU with someone
that doesn't understand simcap, but is indicating = they can also do
codecs 1 and 2 (and each of them with rfc2833). The = answerer could pick
one of those alternate cdsc in the answer:
m=3Daudio 7554 RTP/AVP 1 76
a=3Drtpmap:76 telephone-event


We would probably need to define an additional = attribute in the SDP that
indicates that this "simcap effects the m line = selection" semantic is
being followed.
This approach may confused intermediaries that are = assuming a subset of
codecs in the answer.
3. Define a sort-of backwards compatible usage of = simcap with offer/answer
In this model, the offerer lists all codecs they can = do in the offer.
They include simcap declarations as well. As with = normal offer/answer,
the answerer has to pick a subset, but they use the = simcap declarations
to help them pick a subset which is an allowed = capability. So, in the
example above where the caller can do codecs 0,2,3,4 = along with 76, but
only ONE of 0,2,3,4 at a time, the O/A would look = like this:
OFFER:
m=3Daudio 8778 RTP/AVP 0 1 2 76
a=3Drtpmap:76 telephone-event
a=3Dsqn:0
a=3Dcdsc: 1 audio RTP/AVP 0 76
a=3Dcdsc: 3 audio RTP/AVP 1 76
a=3Dcdsc: 5 audio RTP/AVP 2 76
ANSWER:
m=3Daudio 7554 RTP/AVP 1 76
a=3Drtpmap:76 telephone-event


If, however, the UAS doesn't understand simcap, its = possible that
they'll return an SDP listing all four codecs, and = possibly change them
on the fly. That can be fixed, in general, by = another re-invite which
lists only a single codec. This will work, but might = cause an RTT worth
of media to be sent using a codec different from the = one the UAC
"loaded" into the DSP.
4. Declare that simcap is overkill for this one = problem, and define a
single attribute, a=3Dpickone, which says to choose = only one of the codecs
in the m line.
The "I can do one of N, but only one at a = time" problem, IMHO, the only
capability problem that anyone actually has in real = usage. I will note
that, in fact, this is the only capabilities = question ever asked on
sip-implementors.
A single attribute would easily solve it. If you = want to do rfc2833
along with any one of N other codecs, you could use = fid along with this,
to include an m line with the rfc2833, and then = another m line with the
N codecs and the a=3Dpickone attribute.


One way or another, we need to solve this problem. My = apologies for
bringing this up so late, but I had thought it was = solved (I thought it
implied approach #3 above).... comments on the = various alternatives?
-Jonathan R.
--
Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
dynamicsoft        &nbs= p;           &nbs= p;        East Hanover, NJ 07936 =
jdrosen@dynamicsoft.com      &nbs= p;          FAX: (973) = 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________ =
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic =

------_=_NextPart_001_01C19792.1E9A4290-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 12:56:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22735 for ; Mon, 7 Jan 2002 12:56:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15659 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 12:56:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14191; Mon, 7 Jan 2002 12:23:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14160 for ; Mon, 7 Jan 2002 12:22:58 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21549 for ; Mon, 7 Jan 2002 12:22:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g07HMrVZ008688 for ; Mon, 7 Jan 2002 12:22:53 -0500 (EST) Message-ID: <3C39D94F.2030106@dynamicsoft.com> Date: Mon, 07 Jan 2002 12:22:23 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Let us focus on the major issues Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, Time is running out on completion of the bis spec. We REALLY need to get to a wglc in a few weeks in order to meet the 3gpp release schedules. One of the biggest barriers to that right now are the major open issues that have been discussed on the list. Of the 34 currently open issues, the majority are minor, save SIX: * Issue #113: overlapping INVITE (we agreed to allow overlapping non-INVITE) * Issue #184: maximum message sizes for SIP over UDP, truncated responses. * Issue #266: the heterogeneous error response forking problem * [Several]: Source routing, general proxy routing logic * Issue #232: TLS v. IPSec * Issue #364: offer/counter-offer/answer model I'd like to strongly encourage the group to expend their energies primarily on these issues; the bis editors team has gotten owners assigned for each of these that will push to drive them towards completion (save the TLS v. IPSec nonsense, which is punted to the security team). Please, folks, if you have questions, opinions or concerns, voice them concisely and promptly. I will also be working to close up the other 28 minor issues; on those, I ask people to show restraint against needless argument, and to commit to helping resolve them rather than emailing for emails sake. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 13:26:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23515 for ; Mon, 7 Jan 2002 13:26:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16860 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 13:26:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15413; Mon, 7 Jan 2002 12:52:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15386 for ; Mon, 7 Jan 2002 12:52:53 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22631 for ; Mon, 7 Jan 2002 12:52:51 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g07HqFJ01381; Mon, 7 Jan 2002 09:52:15 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP88088; Mon, 7 Jan 2002 09:51:42 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA12725; Mon, 7 Jan 2002 09:52:14 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15417.57422.418765.411579@thomasm-u1.cisco.com> Date: Mon, 7 Jan 2002 09:52:14 -0800 (PST) To: Jonathan Rosenberg Cc: sip@ietf.org Subject: [Sip] Let us focus on the major issues In-Reply-To: <3C39D94F.2030106@dynamicsoft.com> References: <3C39D94F.2030106@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > * Issue #184: maximum message sizes for SIP over UDP, truncated responses. After all of the discussion, I think that Henning (?) had it right: ignore the issue. This seems like a very deep rathole as you have amply demonstrated, and despite IESG unhappiness with UDP, the cat is already out of the bag here so it would be pointless deprecate UDP. If we do anything, maybe saying that TCP is a MUST implement so that compliant devices aren't built which cannot switch to TCP if this indeed proves to be a problem. > * Issue #232: TLS v. IPSec IPsec is the only thing which helps UDP which is arguably the most vulnerable. People are free to use TLS, but SIP needs to recommend something that covers all of SIP's bases. Period. We cannot mandate something that is going to be useless for many, many cheap and existing UA's. > I'd like to strongly encourage the group to expend their energies > primarily on these issues; the bis editors team has gotten owners > assigned for each of these that will push to drive them towards > completion (save the TLS v. IPSec nonsense, which is punted to the > security team). Please, folks, if you have questions, opinions or > concerns, voice them concisely and promptly. ? Are you saying that this won't be part of bis? Mike _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 13:50:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24548 for ; Mon, 7 Jan 2002 13:50:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA17527 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 13:51:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16685; Mon, 7 Jan 2002 13:19:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16654 for ; Mon, 7 Jan 2002 13:19:01 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23344 for ; Mon, 7 Jan 2002 13:18:59 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21809 for ; Mon, 7 Jan 2002 13:18:28 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA27528 for ; Mon, 7 Jan 2002 13:18:28 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Jan 2002 13:18:26 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57C7B4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'sip@ietf.org'" Date: Mon, 7 Jan 2002 13:18:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP Security Design Team Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org We have appointed the following volunteers to the sip security design team. Eric Rescorla Robert Moskowitz Jari Arrko Jon Peterson Michael Thomas Henning Schultzrinne There were many more volunteers than this. I was overwhelmed and thankful that there were so many people who were able to commit time to this important effort. To them, and to others with interest and skill in this area, I plead with you to stay engaged. The Design Team work is only one step, and there will be a lot of need to use your expertise and ideas in a couple of weeks. Brian for the sip co-chairs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 17:23:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29586 for ; Mon, 7 Jan 2002 17:23:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24071 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 17:23:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22988; Mon, 7 Jan 2002 16:57:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22960 for ; Mon, 7 Jan 2002 16:57:24 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29198 for ; Mon, 7 Jan 2002 16:57:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g07LvPVZ008941; Mon, 7 Jan 2002 16:57:25 -0500 (EST) Message-ID: <3C3A19A6.4070404@dynamicsoft.com> Date: Mon, 07 Jan 2002 16:56:54 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas CC: sip@ietf.org Subject: Re: [Sip] Let us focus on the major issues References: <15417.57422.418765.411579@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Jonathan Rosenberg writes: > > * Issue #184: maximum message sizes for SIP over UDP, truncated > responses. > > After all of the discussion, I think that Henning > (?) had it right: ignore the issue. This seems > like a very deep rathole as you have amply > demonstrated, and despite IESG unhappiness with > UDP, the cat is already out of the bag here so it > would be pointless deprecate UDP. If we do > anything, maybe saying that TCP is a MUST > implement so that compliant devices aren't built > which cannot switch to TCP if this indeed proves > to be a problem. Past history aside, I think that we need to do better than ignore this if we want to pass it through IESG. > > > * Issue #232: TLS v. IPSec > > IPsec is the only thing which helps UDP which is > arguably the most vulnerable. People are free to > use TLS, but SIP needs to recommend something that > covers all of SIP's bases. Period. We cannot > mandate something that is going to be useless > for many, many cheap and existing UA's. I have concluded that arguing this point is futile. The simple fact is that there are cases where TLS is preferable over IPSec, and vice-a-versa. Maybe the only solution we can agree upon is to mandate both as MUST implement ;) > > > I'd like to strongly encourage the group to expend their energies > > primarily on these issues; the bis editors team has gotten owners > > assigned for each of these that will push to drive them towards > > completion (save the TLS v. IPSec nonsense, which is punted to the > > security team). Please, folks, if you have questions, opinions or > > concerns, voice them concisely and promptly. > > ? > > Are you saying that this won't be part of bis? No, security is going to be in bis but is being developed by the security team. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 17:32:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29700 for ; Mon, 7 Jan 2002 17:32:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24594 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 17:32:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23767; Mon, 7 Jan 2002 17:14:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23735 for ; Mon, 7 Jan 2002 17:14:08 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29408 for ; Mon, 7 Jan 2002 17:14:06 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g07ME3VZ008945; Mon, 7 Jan 2002 17:14:04 -0500 (EST) Message-ID: <3C3A1D8C.10407@dynamicsoft.com> Date: Mon, 07 Jan 2002 17:13:32 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Terry L Anderson CC: sip@ietf.org Subject: Re: [Sip] Open Issue #342: SDP in 488 References: <3C362095.D101759B@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Terry L Anderson wrote: > See below >>>I thought it was specified, although perhaps you believe it needs >>>more >>>detail. In bis-04 section 8 and the example in 20.8 seemed clear >>>enough to me. >>> >>Its just an example. Examples don't specify normative text. >> > > True but I thought it illustrated the intent of the sentence in section > 8 > which is normative. No, an example is just not sufficient. >>>If there >>>is no way to query the other end for a list of supported codecs it >>>is difficult to find one in common. >>> >>Thats not true at all. This is why simcap was developed. >> > > I agree simcap helps, but I don't see how to use this in SIP without > 488/OPTIONS. > simcap gives a way to know whether later reINVITEs to other codec are > likely > to succeed (e.g, indicate capability of telephone-event without starting > it > initially), Right. See my post on another thread; this was my misunderstanding of simcap. > but say UA1 sends an INVITE with m line using 18 but > a=cdsc's > indicating support for 0 and 4. If UA2 cannot support 18 but CAN > support > and/or 4, what does it do? It must 488/606 the call. Or, it could possibly return 0 or 4 in the m line. This is one possibility I have proposed in a separate thread. > Should UA2 then > INVITE > with m line of 0 or should the new INVITE still come from UA1? I assume > UA1 > and so UA2 must still inform UA1 of its capabilities by sending a body > in > 488/606. Doing this with cdsc rather than m lines is certainly clearer, > but > UA2 still needs to send a body. Despite the fact that other approaches may make the 488 unneeded, I think I buy the argument that generally being able to declare capabilities in OPTIONS response and 488/606 is a good thing. I am in the process of figuring out where such a specification would live. So, let us consider this issue closed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 17:39:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29822 for ; Mon, 7 Jan 2002 17:39:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24748 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 17:39:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23874; Mon, 7 Jan 2002 17:19:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23843 for ; Mon, 7 Jan 2002 17:19:10 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29482 for ; Mon, 7 Jan 2002 17:19:04 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g07MJ7VZ008949; Mon, 7 Jan 2002 17:19:07 -0500 (EST) Message-ID: <3C3A1EBC.7030406@dynamicsoft.com> Date: Mon, 07 Jan 2002 17:18:36 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #179: Multicast to unicast REGISTER References: <3C2B39B7.4040702@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There being no further comments, I consider this issue closed. We will use 302 with the proposed text below. -Jonathan R. Jonathan Rosenberg wrote: > There have been no comments on this proposal. However, I'd like to amend > > the proposal. I think 302 is more appropriate, in fact. In that case, > the same proposal as below holds, but replace 301 with 302. The caching > would only apply when an Expires header is present. > > Comments? > > -Jonathan R. > > Jonathan Rosenberg wrote: > > >>Issue: >> >>The spec allows for clients to multicast their registrations. >> > Presumably, > >>refreshes are also sent multicast. Sometimes this is the right thing, >> > but if > >>the purpose of multicast REGISTER is just discovery, the client should >>probably unicast after it discovers, and then revert to multicast >> > again only > >>if that server becomes unavailable. However, the spec is silent on >> > this > >>case. Should we discuss? >> >>Discussion points: >> >>A 301 can be sent by the registar, providing a unicast address (this >> > is only > >>now possible in bis-05 due to the new multicast treatment). However, >> > the 301 > >>would be cached indefinitely at the client, and its not clear what the >>behavior is for cached redirects on failure. If we specify that it >> > retries > >>the original request that generated the 3xx, then the registrar has a >>mechanism it can use. >> >>Proposal: >> >> * add text to 301 section saying that if a cached contact fails, try >> > the > >>original URI again >> >> * add text in the registration section, mentioning that this is a >> > useful > >>thing to do. Otherwise, people may not be prepared to have their >>registrations redirected, even though the spec does allow it. >> >>-Jonathan R. >> >>--- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >> >>_______________________________________________ >>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> >> > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 17:43:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29887 for ; Mon, 7 Jan 2002 17:43:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24793 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 17:43:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23935; Mon, 7 Jan 2002 17:20:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23904 for ; Mon, 7 Jan 2002 17:20:54 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29510 for ; Mon, 7 Jan 2002 17:20:52 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g07MKtVZ008952; Mon, 7 Jan 2002 17:20:55 -0500 (EST) Message-ID: <3C3A1F28.7000109@dynamicsoft.com> Date: Mon, 07 Jan 2002 17:20:24 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #259: Proxies Honoring Expires References: <3C2AC076.80708@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There was only one comment on this proposal, from Jo, which agreed to have proxies ignore Expires. I will therefore consdier the proposal accepted and the issue closed. -Jonathan R. Jonathan Rosenberg wrote: > about a minimum value for timer C. However, they are orthogonal> > > Issue: When a proxy receives an INVITE with an Expires header, what > should the proxy do when that expiration time arrives? Should it CANCEL > the INVITE, or just ignore it? > > Discussion: CANCELing it would give the proxy a way to clean up its > state faster without relying on the UAs to help. The big question is > whether or not something very robust is needed or not. Robert had posted > > a listing of four cases to consider: > > If an Expires header > is present with a shorter value than what the proxy > uses for timer C one of four things will happen: > > 1) the receiving endpoint with 408 the request - the > proxy's client transaction gets to enter > the completed state > 2) the requesting endpoint CANCELs and the receiving > endpoint returns a 487 - the proxy's client transaction > gets to enter the completed state > 3) the requesting endpoint CANCELS but the receiving > endpoint fails to return a 487 - the proxy's client > transaction enters the terminal state after > timer C expires > 4) both endpoints (or the network infrastructure) are > misbehaving - the proxy's client transaction enters > the terminal state after timer C expires. > > > If the proxy honors Expires, case (4) will change; instead, the client > transaction will be able the terminal state after the expiration, as > opposed to waiting for timer C (as it seems timer C is effectively > infinity for proxies). So, is case 4 a frequent enough case to merit > this treatment? > > An interesting point is what happens when there are multiple proxies. > Each will CANCEL at the same time. is that bad? If you work through the > flows, turns out its not. There is no extra messages sent beyond what > would be sent if the UA cancels. However, it will be a race condition to > > see whether a 408 or 487 is received by the UAC (depending on whether > the UAS generates a 408 on expiration, or the proxy CANCELs and that > reaches the UAS first). Not clear that there is anything wrong with > that. > > Proposal: KISS; proxies ignore Expires > > -Jonathan R. > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 17:46:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29941 for ; Mon, 7 Jan 2002 17:46:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24838 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 17:46:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24023; Mon, 7 Jan 2002 17:23:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23992 for ; Mon, 7 Jan 2002 17:23:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29577 for ; Mon, 7 Jan 2002 17:23:12 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g07MMUVZ008958; Mon, 7 Jan 2002 17:22:31 -0500 (EST) Message-ID: <3C3A1F88.3000501@dynamicsoft.com> Date: Mon, 07 Jan 2002 17:22:00 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Henning Schulzrinne CC: sip@ietf.org Subject: Re: [Sip] Open Issue #204: Password in To/From URL References: <3C2AF995.E7FB6880@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There was only one comment in favor of the modified proposal to allow, which was from Henning, who supported it. Therefore, I consider this issue closed. Password can appear in To or From, really just as an extension of the user part, as Henning describes. -Jonathan R. Henning Schulzrinne wrote: >>Another point worth noting, thinking about it some more, is that in >> > the > >>most basic case, the r-uri will be rewritten with the registered >> > contact > >>of the called party, so the called party won't ever see the password >>(I'm assuming that the password is NOT part of the address-of-record). >>Thus, it does need to be in the To field to get to the called party, >> > as > >>it has e2e significance supposedly.... >> >>OK, so now I am going to back track, and rather propose to allow >> >>the password in the To field, documenting its real uses and >> > limitations > >>of course. >> >>Comments? >> > > The fewer special cases, the better, so allowing it (with caveats) in > the three places seems like the right approach. It really is just a user > name convention (something that some people emulate in email, but which > requires special software help, as in joe+ or joe+lists.) > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 17:49:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00031 for ; Mon, 7 Jan 2002 17:49:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24869 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 17:49:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24641; Mon, 7 Jan 2002 17:33:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24610 for ; Mon, 7 Jan 2002 17:33:28 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29729 for ; Mon, 7 Jan 2002 17:33:26 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g07MXRVZ008971; Mon, 7 Jan 2002 17:33:28 -0500 (EST) Message-ID: <3C3A2219.3000905@dynamicsoft.com> Date: Mon, 07 Jan 2002 17:32:57 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Penfield CC: Henry Sinnreich , "'Robert Sparks'" , sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) References: <001d01c18efa$dcde2a00$2300000a@acmepacket.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This thread has stalled, and I think it requires some further input before we can resolve it. The issue was this: what minimum timer do we mandate for a proxy to hang onto invite transaction state after receiving 1xx? The issue is that some PSTN systems (american airlines in particular), appear to use early media while a user is on hold waiting, or using the DTMF based IVR system. The result is that a call from a PC to a PSTN number could, in theory go legitimately unanswered for hours, perhaps. This would require that Timer C in proxies be on the order of hours, which is quite large. An alternative is to not consider this case, and choose a smaller value, on the order of minutes. Both can result in DoS attacks, although in this case, the proxy shouldn't be storing transaction state for unauthenticated requests. Determining whether or not to go with a large value depends a lot on how common such systems are in the PSTN, and what the expectation is for them to be properly supported. Further inputs? -Jonathan R. Bob Penfield wrote: >>>I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>> > > The same problem occurs using old-world TDM equipment. If I use my > calling > card account to call AA, it hangs up after about a minute because the > calling card platform has a 60 second answer timer. AA is trying to save > money by having their ACD not return an answer and thus they don't have > to > pay for the 800 call. > > BTW, all billing is based on answer (2xx for SIP) being returned by the > called party. Some systems (usually in hotels) do use a timer when > answer > cannot be determined reliably (or they don't care). > > I'm curious as to whether this was isolated to a proxy or is it possible > the > TDM side of the gateway is dropping the call? If gateways have answer > timers > on this order of magnitude, having a really long timer in the proxy > won't > help. > > In any event, do we really need to support these cheaters in SIP and > open > ourselves to DOS attacks? > > >>I have exactly the same experience. >>As for: >> >> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, >>> >>I don't know how to tweak to and I don't ever want to know. >> >>Is there a better approach to fix the timer value or am I missing >>something? >> >>Thanks, Henry >> >> >>>-----Original Message----- >>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of >>> >>Robert >> >>>Sparks >>>Sent: Thursday, December 27, 2001 9:57 AM >>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks >>>Cc: sip@ietf.org >>>Subject: [Sip] Default value for Timer C (was #282) >>> >>>I'm talking about a _real problem_ that I have >>>_right now_ with the UAs on my desk and the gateways >>>I have access to. I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>>Try it - call +18004337300 - my environment drops the unanswered >>>call about 58 seconds into the first menu (yes, the first menu >>>is over a minute long). >>> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, I could >>>work around it. But what about my tweak-phobic aquaintances >>>and relatives? >>> >>>In this case, the endpoints are dropping the call, but if I had >>>otherwise behaving endpoints, and a proxy in the middle with a >>>_default_ Timer C value that is too small, I am left with >>>at least one well-known service that just doesn't work. >>> >>>Now, we could get into a discussion about whether or not a service >>>_should_ run a whole bunch of time in an early media state, but >>>that's rather moot - we've worked really hard to make the system >>>allow it, and it will be used. We're here on purpose, not by >>>misfortune of oversight. >>> >>>As for your last paragraph - who says early media has to be free? >>> >>>RjS >>> >>> >>> >>>>From: Bob Penfield [mailto:bpenfield@acmepacket.com] >>>> >>>>>>If this is acceptable, it still leaves us with the question >>>>>>of what value we should recommend. I propose something >>>>>>long - order of .5 to 1 hour (remember that calls stay in a >>>>>>provisional state with early media when you are in the queue >>>>>>to talk to an AA representative). >>>>>> >>>>> >>>>>Egads, thats a long time! Your point on early media is well >>>>> > taken, > >>>>>though. Arguably, if this case happens, 1 hour is not even >>>>> >>>>enough, since >>>> >>>>>I have certainly been on hold for durations longer than >>>>> >>>>that. Probably 4 >>>> >>>>>hours is more reasonable. Once you've set the timer this >>>>> >>>>high, it may as >>>> >>>>>well be any finite number as far as the proxy is concerned. The >>>>> >>only >> >>>>>value in having a number at all (as opposed to infinity) is >>>>> >>>>very long >>>> >>>>>term garbage collection. You will get NO DoS attack prevention >>>>> >>from >> >>>>>numbers of this magnitude. You really need to be careful, >>>>> >>>>as a proxy, to >>>> >>>>>not create transaction state unless the request is >>>>> >>>>authenticated somehow. >>>> >>>>I don't think this really applies. I believe that most ACD >>>>systems that put >>>>you on hold actually do answer the call. Especially ones that >>>>have DTMF >>>>menus since some carriers block the caller to callee >>>>connection until it is >>>>answered. Many TDM switches that I have experience with will >>>>tear down an >>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3 >>>>minute timer >>>>would be adequate. >>>> >>>>But, this is not the TDM world. So, if we want to provide for >>>>unanswered >>>>calls being queued for long periods of time, maybe we could >>>>require the UAS >>>>to send periodic provisional responses and the proxy could >>>>reset Timer C. >>>>But that may be getting to complicated. >>>> >>>>Service providers who charge for these calls don't want their >>>>resources used >>>>for free for such a long period of time. >>>> >>>>cheers, >>>>(-:bob >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of >>>> > sip > >>>_______________________________________________ >>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 18:14:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00554 for ; Mon, 7 Jan 2002 18:14:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26095 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 18:14:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25001; Mon, 7 Jan 2002 17:51:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24898 for ; Mon, 7 Jan 2002 17:51:50 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00105 for ; Mon, 7 Jan 2002 17:51:43 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g07Mp6VZ008984; Mon, 7 Jan 2002 17:51:07 -0500 (EST) Message-ID: <3C3A263B.6050907@dynamicsoft.com> Date: Mon, 07 Jan 2002 17:50:35 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org, John.Hearty@Level3.com Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C3658ED.CF9E8190@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > > I don't have anything against what you propose in the draft. So, let's > continue the discussion based on that, because the issues I have are > pretty much the same. > > Q1: > > The draft does also, however, say that the re-INVITE may not work for > all nodes (eg PSTN gateways), so that's why I don't think it should be > general behaviour. As I've pointed out, if its not at least SHOULD strength, it cannot be counted on, and it needs to be. > Also, there may be some nodes (maybe the media > server) which from a functional point of view does not want to send a > re-INVITE. For example, if I call a media server from my SIP phone, and > the media server detects a media failure, it may not make such sense for > it to generate a re-INVITE, which may end up in my other phone... Your phone would normally 481 this because it contains tags. There is no risk of accidentally getting a call setup elsewhere. > > > Q2: > > Chapter 5 says that the re-INVITE must arrive at UA3, ie the backup, > since UA2 generated ICMP. However, shouldn't the first re-INVITE be sent > by UA1 to UA2 (where the initial INVITE was sent) in any case, in case > the media failure was temporary, or UA2 did a quick reboot? Then, it > that fails the UA1 will try UA3 etc. The assumption is of some kind of proxy which will definitively know about the failure of UA2 and route the request to UA3 instead. > > Also, if UA2 recovers by itself, and UA1 has contacted UA3 there is a > chance that UA2 will start sending media again, which may get messed up > with the media from UA3. UA2 may even detect a media failure itself (eg > if new ports were allocated by UA1 for UA3), so it may generate a > re-INVITE. AND, that re-INVITE may not even reach UA1 - at least not if > it's routed according to Chapter 5. All of which can happen for any reliable system that maintains backups. This mechanism merely provides a nice distributed way to replicate the state. You still need to ensure consistent views of which element is actually up/down. > > > Q3: > > Also, the draft doesn't say anything about the case where BOTH nodes > detect the media failure. Assume that both UA1 and UA2 detects the media > failure. The re-INVITE sent by UA1 may end up at UA3, and the re-INVITE > sent by UA2 may end up at UA4, in which case things may get messy. One > of my phones may send the re-INVITE, and suddenly my other phone starts > ringing... or something like that... See above. Requests are not generally routed to alternates gratuitously. The above case would only happen if both ends actually fail simultaneously. I am not that concerned about this situation. > > > Q4: > > About the "server group ID": > > First, if it's only used only in the To tag, will it work if the CALLED > party generates the re-INVITE? > Shouldn't the ID also be in the From tag, so that the re-INVITE works in > both directions of the call? It needs to be included in From/To, as appropriate, by any element that wishes to recover. However, since it is an implementation decision, it need not be standardized. Nothing about this concept needs to, or should, go into bis. > > Also, does an empty ID value mean that no backup node exist? > > I also think we should investigate if the "server group ID" you propose > affects issues like REFER, 3pcc etc. > I am not saying it does affect, but IF... :) No, it does not. Please do not make issues where there are none. I am trying to resolve what I believe is a fairly minor issue, and I feel you are taking it farther and farther astray. The issue is simple - on detection of a media failure, do we specify that a UA SHOULD generate a re-INVITE, in order to allow the far end to reconsistute session and dialog state in the event the media failure was due to a failed endpoint? The cost is low, the potential benefits are high. I say yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 7 18:17:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00609 for ; Mon, 7 Jan 2002 18:17:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA26171 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 18:17:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25113; Mon, 7 Jan 2002 17:56:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25083 for ; Mon, 7 Jan 2002 17:56:21 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00221 for ; Mon, 7 Jan 2002 17:56:19 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id WAA18473; Mon, 7 Jan 2002 22:55:52 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA02406; Mon, 7 Jan 2002 22:56:14 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 15:56:09 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B3710D@n0214idc1.oss.level3.com> To: jdrosen@dynamicsoft.com, bpenfield@acmepacket.com Cc: Henry.Sinnreich@wcom.com, rsparks@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) Date: Mon, 7 Jan 2002 15:56:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I agree with Bob. AA is apparently cheating here, doing all their IVR functions without returning answer. I vote for the alternative, choosing a value on the order of minutes (not more than maybey three or four). John Hearty Level3 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, January 07, 2002 3:33 PM To: Bob Penfield Cc: Henry Sinnreich; 'Robert Sparks'; sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) This thread has stalled, and I think it requires some further input before we can resolve it. The issue was this: what minimum timer do we mandate for a proxy to hang onto invite transaction state after receiving 1xx? The issue is that some PSTN systems (american airlines in particular), appear to use early media while a user is on hold waiting, or using the DTMF based IVR system. The result is that a call from a PC to a PSTN number could, in theory go legitimately unanswered for hours, perhaps. This would require that Timer C in proxies be on the order of hours, which is quite large. An alternative is to not consider this case, and choose a smaller value, on the order of minutes. Both can result in DoS attacks, although in this case, the proxy shouldn't be storing transaction state for unauthenticated requests. Determining whether or not to go with a large value depends a lot on how common such systems are in the PSTN, and what the expectation is for them to be properly supported. Further inputs? -Jonathan R. Bob Penfield wrote: >>>I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>> > > The same problem occurs using old-world TDM equipment. If I use my > calling > card account to call AA, it hangs up after about a minute because the > calling card platform has a 60 second answer timer. AA is trying to save > money by having their ACD not return an answer and thus they don't have > to > pay for the 800 call. > > BTW, all billing is based on answer (2xx for SIP) being returned by the > called party. Some systems (usually in hotels) do use a timer when > answer > cannot be determined reliably (or they don't care). > > I'm curious as to whether this was isolated to a proxy or is it possible > the > TDM side of the gateway is dropping the call? If gateways have answer > timers > on this order of magnitude, having a really long timer in the proxy > won't > help. > > In any event, do we really need to support these cheaters in SIP and > open > ourselves to DOS attacks? > > >>I have exactly the same experience. >>As for: >> >> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, >>> >>I don't know how to tweak to and I don't ever want to know. >> >>Is there a better approach to fix the timer value or am I missing >>something? >> >>Thanks, Henry >> >> >>>-----Original Message----- >>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of >>> >>Robert >> >>>Sparks >>>Sent: Thursday, December 27, 2001 9:57 AM >>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks >>>Cc: sip@ietf.org >>>Subject: [Sip] Default value for Timer C (was #282) >>> >>>I'm talking about a _real problem_ that I have >>>_right now_ with the UAs on my desk and the gateways >>>I have access to. I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>>Try it - call +18004337300 - my environment drops the unanswered >>>call about 58 seconds into the first menu (yes, the first menu >>>is over a minute long). >>> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, I could >>>work around it. But what about my tweak-phobic aquaintances >>>and relatives? >>> >>>In this case, the endpoints are dropping the call, but if I had >>>otherwise behaving endpoints, and a proxy in the middle with a >>>_default_ Timer C value that is too small, I am left with >>>at least one well-known service that just doesn't work. >>> >>>Now, we could get into a discussion about whether or not a service >>>_should_ run a whole bunch of time in an early media state, but >>>that's rather moot - we've worked really hard to make the system >>>allow it, and it will be used. We're here on purpose, not by >>>misfortune of oversight. >>> >>>As for your last paragraph - who says early media has to be free? >>> >>>RjS >>> >>> >>> >>>>From: Bob Penfield [mailto:bpenfield@acmepacket.com] >>>> >>>>>>If this is acceptable, it still leaves us with the question >>>>>>of what value we should recommend. I propose something >>>>>>long - order of .5 to 1 hour (remember that calls stay in a >>>>>>provisional state with early media when you are in the queue >>>>>>to talk to an AA representative). >>>>>> >>>>> >>>>>Egads, thats a long time! Your point on early media is well >>>>> > taken, > >>>>>though. Arguably, if this case happens, 1 hour is not even >>>>> >>>>enough, since >>>> >>>>>I have certainly been on hold for durations longer than >>>>> >>>>that. Probably 4 >>>> >>>>>hours is more reasonable. Once you've set the timer this >>>>> >>>>high, it may as >>>> >>>>>well be any finite number as far as the proxy is concerned. The >>>>> >>only >> >>>>>value in having a number at all (as opposed to infinity) is >>>>> >>>>very long >>>> >>>>>term garbage collection. You will get NO DoS attack prevention >>>>> >>from >> >>>>>numbers of this magnitude. You really need to be careful, >>>>> >>>>as a proxy, to >>>> >>>>>not create transaction state unless the request is >>>>> >>>>authenticated somehow. >>>> >>>>I don't think this really applies. I believe that most ACD >>>>systems that put >>>>you on hold actually do answer the call. Especially ones that >>>>have DTMF >>>>menus since some carriers block the caller to callee >>>>connection until it is >>>>answered. Many TDM switches that I have experience with will >>>>tear down an >>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3 >>>>minute timer >>>>would be adequate. >>>> >>>>But, this is not the TDM world. So, if we want to provide for >>>>unanswered >>>>calls being queued for long periods of time, maybe we could >>>>require the UAS >>>>to send periodic provisional responses and the proxy could >>>>reset Timer C. >>>>But that may be getting to complicated. >>>> >>>>Service providers who charge for these calls don't want their >>>>resources used >>>>for free for such a long period of time. >>>> >>>>cheers, >>>>(-:bob >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of >>>> > sip > >>>_______________________________________________ >>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jan 7 19:26:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01681 for ; Mon, 7 Jan 2002 19:26:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28415 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 19:26:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28141; Mon, 7 Jan 2002 19:08:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28112 for ; Mon, 7 Jan 2002 19:07:59 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01486 for ; Mon, 7 Jan 2002 19:07:57 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g0806Zk05792 for ; Mon, 7 Jan 2002 16:06:54 -0800 (PST) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABT23806; Mon, 7 Jan 2002 16:06:53 -0800 (PST) From: "Cullen Jennings" To: Date: Mon, 7 Jan 2002 16:15:05 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C39D94F.2030106@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Sip] Issue #364: correlation problems Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It seems like a generally bad thing that we do not have a way to correlate a SSRC in a RTP stream with the media stream in the SDP that it relates to. Similarly it should be easier to correlate media stream in SDP from one transaction to the next (fid please?). The endlessly growing SDP is, ah, ugly. If we solved our RTP <-> SDP <-> dialog correlation problems - would Issue 364 go away? Thanks, Cullen _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jan 7 19:54:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01983 for ; Mon, 7 Jan 2002 19:54:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA29158 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 19:54:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28927; Mon, 7 Jan 2002 19:34:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28896 for ; Mon, 7 Jan 2002 19:33:59 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01810 for ; Mon, 7 Jan 2002 19:33:57 -0500 (EST) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g080Xwl00247; Mon, 7 Jan 2002 19:33:59 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Default value for Timer C (was #282) Date: Mon, 7 Jan 2002 19:36:10 -0500 Message-ID: <001201c197dc$787530f0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3C3A2219.3000905@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > The issue was this: what minimum timer do we mandate for a > proxy to hang > onto invite transaction state after receiving 1xx? The issue is that > some PSTN systems (american airlines in particular), appear > to use early > media while a user is on hold waiting, or using the DTMF based IVR > system. The result is that a call from a PC to a PSTN number > could, in > theory go legitimately unanswered for hours, perhaps. This > would require > that Timer C in proxies be on the order of hours, which is > quite large. > > An alternative is to not consider this case, and choose a > smaller value, > on the order of minutes. > > Both can result in DoS attacks, although in this case, the proxy > shouldn't be storing transaction state for unauthenticated requests. > > Determining whether or not to go with a large value depends a > lot on how > common such systems are in the PSTN, and what the expectation is for > them to be properly supported. > > Further inputs? Using a reasonable Expires header allows a value to be communicated to the UAS to send a final response within Expires time. Proxies can shorten the value if desired. Thus a UAS can allow an infinite setup time when nobody cares. And a UAS is forced to switch from a setup state to final response when a device within the dialogue refuses to allow indefinite setup times because of resource/billing issues. Concerning the 'hold waiting' scenario, it forces the gateway to switch to a 200 prior to expiration or send 408 upon expiration. I think the recommended default time should be around 3-5 minutes. However for backward compatibility, the UAC/proxy might want to add an Expires header since the lack of it currently indicates infinity. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jan 7 22:32:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05797 for ; Mon, 7 Jan 2002 22:32:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA03423 for sip-archive@odin.ietf.org; Mon, 7 Jan 2002 22:32:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02892; Mon, 7 Jan 2002 22:14:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02863 for ; Mon, 7 Jan 2002 22:14:18 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04676 for ; Mon, 7 Jan 2002 22:14:15 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 118984CE74 for ; Mon, 7 Jan 2002 22:14:18 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id WAA07816; Mon, 7 Jan 2002 22:14:15 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id WAA29267; Mon, 7 Jan 2002 22:11:36 -0500 (EST) Date: Mon, 7 Jan 2002 22:11:36 -0500 (EST) Message-Id: <200201080311.WAA29267@fish.research.att.com> To: sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In the circuit switch world, the equivalent of "Timer C" exists. On a 5ESS, ringback turns to fast busy after 3 minutes. On a 4ESS, it happens after 90 seconds. (Both figures were as of a few years ago, but I doubt they have changed). Perhaps someone from Nortel could speak of the DMS switches. Also as of a few years ago, business customers paid for ring time, so if still true, it is not clear why AA is "cheating". So a timeout value of a couple of minutes (like 4) would work just fine for calls into the PSTN, and would only get hit for a high-and-dry type of defect. Bill Marshall wtm@research.att.com -----original message----- From: John.Hearty@Level3.com Subject: RE: [Sip] Default value for Timer C (was #282) Date: Mon, 7 Jan 2002 15:56:14 -0700 I agree with Bob. AA is apparently cheating here, doing all their IVR functions without returning answer. I vote for the alternative, choosing a value on the order of minutes (not more than maybey three or four). John Hearty Level3 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, January 07, 2002 3:33 PM To: Bob Penfield Cc: Henry Sinnreich; 'Robert Sparks'; sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) This thread has stalled, and I think it requires some further input before we can resolve it. The issue was this: what minimum timer do we mandate for a proxy to hang onto invite transaction state after receiving 1xx? The issue is that some PSTN systems (american airlines in particular), appear to use early media while a user is on hold waiting, or using the DTMF based IVR system. The result is that a call from a PC to a PSTN number could, in theory go legitimately unanswered for hours, perhaps. This would require that Timer C in proxies be on the order of hours, which is quite large. An alternative is to not consider this case, and choose a smaller value, on the order of minutes. Both can result in DoS attacks, although in this case, the proxy shouldn't be storing transaction state for unauthenticated requests. Determining whether or not to go with a large value depends a lot on how common such systems are in the PSTN, and what the expectation is for them to be properly supported. Further inputs? -Jonathan R. Bob Penfield wrote: >>>I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>> > > The same problem occurs using old-world TDM equipment. If I use my > calling > card account to call AA, it hangs up after about a minute because the > calling card platform has a 60 second answer timer. AA is trying to save > money by having their ACD not return an answer and thus they don't have > to > pay for the 800 call. > > BTW, all billing is based on answer (2xx for SIP) being returned by the > called party. Some systems (usually in hotels) do use a timer when > answer > cannot be determined reliably (or they don't care). > > I'm curious as to whether this was isolated to a proxy or is it possible > the > TDM side of the gateway is dropping the call? If gateways have answer > timers > on this order of magnitude, having a really long timer in the proxy > won't > help. > > In any event, do we really need to support these cheaters in SIP and > open > ourselves to DOS attacks? > > >>I have exactly the same experience. >>As for: >> >> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, >>> >>I don't know how to tweak to and I don't ever want to know. >> >>Is there a better approach to fix the timer value or am I missing >>something? >> >>Thanks, Henry >> >> >>>-----Original Message----- >>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of >>> >>Robert >> >>>Sparks >>>Sent: Thursday, December 27, 2001 9:57 AM >>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks >>>Cc: sip@ietf.org >>>Subject: [Sip] Default value for Timer C (was #282) >>> >>>I'm talking about a _real problem_ that I have >>>_right now_ with the UAs on my desk and the gateways >>>I have access to. I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>>Try it - call +18004337300 - my environment drops the unanswered >>>call about 58 seconds into the first menu (yes, the first menu >>>is over a minute long). >>> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, I could >>>work around it. But what about my tweak-phobic aquaintances >>>and relatives? >>> >>>In this case, the endpoints are dropping the call, but if I had >>>otherwise behaving endpoints, and a proxy in the middle with a >>>_default_ Timer C value that is too small, I am left with >>>at least one well-known service that just doesn't work. >>> >>>Now, we could get into a discussion about whether or not a service >>>_should_ run a whole bunch of time in an early media state, but >>>that's rather moot - we've worked really hard to make the system >>>allow it, and it will be used. We're here on purpose, not by >>>misfortune of oversight. >>> >>>As for your last paragraph - who says early media has to be free? >>> >>>RjS >>> >>> >>> >>>>From: Bob Penfield [mailto:bpenfield@acmepacket.com] >>>> >>>>>>If this is acceptable, it still leaves us with the question >>>>>>of what value we should recommend. I propose something >>>>>>long - order of .5 to 1 hour (remember that calls stay in a >>>>>>provisional state with early media when you are in the queue >>>>>>to talk to an AA representative). >>>>>> >>>>> >>>>>Egads, thats a long time! Your point on early media is well >>>>> > taken, > >>>>>though. Arguably, if this case happens, 1 hour is not even >>>>> >>>>enough, since >>>> >>>>>I have certainly been on hold for durations longer than >>>>> >>>>that. Probably 4 >>>> >>>>>hours is more reasonable. Once you've set the timer this >>>>> >>>>high, it may as >>>> >>>>>well be any finite number as far as the proxy is concerned. The >>>>> >>only >> >>>>>value in having a number at all (as opposed to infinity) is >>>>> >>>>very long >>>> >>>>>term garbage collection. You will get NO DoS attack prevention >>>>> >>from >> >>>>>numbers of this magnitude. You really need to be careful, >>>>> >>>>as a proxy, to >>>> >>>>>not create transaction state unless the request is >>>>> >>>>authenticated somehow. >>>> >>>>I don't think this really applies. I believe that most ACD >>>>systems that put >>>>you on hold actually do answer the call. Especially ones that >>>>have DTMF >>>>menus since some carriers block the caller to callee >>>>connection until it is >>>>answered. Many TDM switches that I have experience with will >>>>tear down an >>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3 >>>>minute timer >>>>would be adequate. >>>> >>>>But, this is not the TDM world. So, if we want to provide for >>>>unanswered >>>>calls being queued for long periods of time, maybe we could >>>>require the UAS >>>>to send periodic provisional responses and the proxy could >>>>reset Timer C. >>>>But that may be getting to complicated. >>>> >>>>Service providers who charge for these calls don't want their >>>>resources used >>>>for free for such a long period of time. >>>> >>>>cheers, >>>>(-:bob >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of >>>> > sip > >>>_______________________________________________ >>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 8 00:18:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07324 for ; Tue, 8 Jan 2002 00:18:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA06059 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 00:18:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04924; Mon, 7 Jan 2002 23:50:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA04892 for ; Mon, 7 Jan 2002 23:50:23 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07072 for ; Mon, 7 Jan 2002 23:50:21 -0500 (EST) Received: from cowboys (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id g085rmM21851 for ; Mon, 7 Jan 2002 23:53:49 -0600 Message-ID: <000901c19800$9babe400$bc8c0a40@dynamicsoft.com> From: "Dean Willis" To: Date: Mon, 7 Jan 2002 22:54:50 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Slides for IETF 52? Please check . . . Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think (which is dangerous) that I've posted all the slides people sent me for the proceedings of the SIP WG meeting at IETF 52. Please check and make sure yours are there. If not, please resend and hound me until they appear . . . http://www.softarmor.com/sipwg/meets/ietf52/slides -- Dean _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 8 01:21:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08351 for ; Tue, 8 Jan 2002 01:21:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA16522 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 01:21:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08175; Tue, 8 Jan 2002 01:05:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08088 for ; Tue, 8 Jan 2002 01:05:16 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08237 for ; Tue, 8 Jan 2002 01:05:15 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0865AK29787; Tue, 8 Jan 2002 07:05:10 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.14] (may be forged)) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g08659hO028468; Tue, 8 Jan 2002 08:05:09 +0200 (EET) Message-ID: <3C3A8BEA.80F74FB6@lmf.ericsson.se> Date: Tue, 08 Jan 2002 08:04:26 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, John.Hearty@Level3.com Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C3658ED.CF9E8190@lmf.ericsson.se> <3C3A263B.6050907@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Q3: >> >>Also, the draft doesn't say anything about the case where BOTH nodes >>detect the media failure. Assume that both UA1 and UA2 detects the media >>failure. The re-INVITE sent by UA1 may end up at UA3, and the re-INVITE >>sent by UA2 may end up at UA4, in which case things may get messy. One >>of my phones may send the re-INVITE, and suddenly my other phone starts >>ringing... or something like that... >See above. Requests are not generally routed to alternates gratuitously. >The above case would only happen if both ends actually fail >simultaneously. I am not that concerned about this situation. NONE of the end nodes have to fail. BOTH may, however, detect the media failure simuntaneously, due to an error in the IP network, in which case BOTH would generate re-INVITE - and what I described above may happend. >>Q4: >> >>About the "server group ID": >> >>First, if it's only used only in the To tag, will it work if the CALLED >>party generates the re-INVITE? > >>Shouldn't the ID also be in the From tag, so that the re-INVITE works in >>both directions of the call? > >It needs to be included in From/To, as appropriate, by any element that >wishes to recover. However, since it is an implementation decision, it >need not be standardized. Nothing about this concept needs to, or >should, go into bis. I agree. And, since that's the case, I also wonder if using the tags is the right way to go. A UA may not know to which "server group" it belongs, or the group may change due to whatever reasons, so if we would use a new header instead some administration proxy could insert that header. However, since this is NOT one of the major issues you listed in another mail we should probably not spend too much time on it now, but let's keep it in mind... >The issue is simple - on detection of a media failure, do we specify >that a UA SHOULD generate a re-INVITE, in order to allow the far end to >reconsistute session and dialog state in the event the media failure was >due to a failed endpoint? The cost is low, the potential benefits are >high. I say yes. What do you mean by "failed endpoint"? A SIP endpoint? Does this mean that the node have to check that the ICMP message actually came from the remote SIP user (and not, for example, from an intermediate router) before it decides if to send a re-INVITE or not? I do NOT have anything against adding what you propose as a SHOULD to bis, but I would like the text to say that it should be done only when the client is pretty sure that the remote SIP endpoint really has failed, and that a re-INVITE would do any good. Otherwise the network could be overloaded with "useless" re-INVITEs when there is a major failure in the IP network, but the SIP nodes are working just fine... In this case I think we would even avoid many of the issues above (Q3, for example). Also, the UA MUST have UAC capabilities (a media server MAY only have UAS capabilities, for example) to be able to send the re-INVITE. Also, we shall remember that the re-INVITE race condition case is still an open issue. YES, we WILL (I hope :) solve it, but we do NOT yet know HOW it will be solved. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 8 02:02:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12235 for ; Tue, 8 Jan 2002 02:02:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA17654 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 02:02:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17160; Tue, 8 Jan 2002 01:48:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA17129 for ; Tue, 8 Jan 2002 01:48:51 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08574 for ; Tue, 8 Jan 2002 01:48:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g086mZVZ009172; Tue, 8 Jan 2002 01:48:36 -0500 (EST) Message-ID: <3C3A9625.5090408@dynamicsoft.com> Date: Tue, 08 Jan 2002 01:48:05 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Sanjay Dhand CC: SIP Mailing List Subject: Re: [Sip] Authentication: qop/cnonce issue Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Going through old emails. As far as I can tell, this appears as yet another bug in rfc2617. I suspect the proper solution is that you can only use MD5-sess if a qop directive is issued. -Jonathan R. Sanjay Dhand wrote: > Hi All, > > I have a query regarding "qop" and "cnonce" fields in Digest > Authentication procedure. Looks like some gap in the specs. Please > provide your input. > > The problem is that if qop parameter does not arrive in the Challenge (401/407) and the algo for the session is "MD5-sess" then Hash Key A1 is built with "cnonce-value" at the client, but "cnonce-value" is not sent to the Server in the subsquent Requests. > > Then How will the Server decode the response without the "cnonce-value"? > > Does it mean that if Algo is "MD5-Sess", then qop parameter MUST be supplied to the client in the Challenge? > > Quoted from RFC 2617, Sec 3.2.2: > > "If qop (Quality of Protection) is not sent to the Client then cnonce > value and nonce-count value MUST NOT be specified in the subsquents > requests." > > AND (construction of the Hash Key A1) > > If Algo is "MD5-sess" then A1 is calculated as > A1 =H(unq(username-value) ":" unq(realm-value) ":" passwd ":" > unq(nonce-value) ":" unq(cnonce-value) > > where A1 is the Session Key for authentication of subsquent requests and > responses. > > A1 is used to calculate the response-digest along with the second hash > Key A2. > > Best regards, > > Sanjay Dhand > > ipDialog India Pvt Ltd > 453, Udyog Vihar phase 5, > Gurgaon INDIA. > > ph: (91) (120) 6399051, 6399657/58 > cell: 9810309914 > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 8 04:31:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18029 for ; Tue, 8 Jan 2002 04:31:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA21565 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 04:31:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20965; Tue, 8 Jan 2002 04:15:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20861 for ; Tue, 8 Jan 2002 04:15:47 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17924 for ; Tue, 8 Jan 2002 04:15:45 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 8 Jan 2002 09:16:11 UT Received: from gbnewp0796m ([193.195.52.113]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 8 Jan 2002 09:18:18 +0000 From: "James Undery" To: "'Jonathan Rosenberg'" , "'Sanjay Dhand'" Cc: "'SIP Mailing List'" Subject: RE: [Sip] Authentication: qop/cnonce issue Date: Tue, 8 Jan 2002 09:18:17 -0000 Message-ID: <005201c19825$69316020$7134c3c1@eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3C3A9625.5090408@dynamicsoft.com> X-OriginalArrivalTime: 08 Jan 2002 09:18:18.0370 (UTC) FILETIME=[68DE5E20:01C19825] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Unfortunately, this is a backwardly compatibility issue with rfc2069 (that doesn't quite work). There is a circle of SHOULDs and MUSTs that I think cover it in the description of the digest challange and response parameters (3.2.1 & 3.2.2), although it would be better as explicit. James > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: 08 January 2002 06:48 > To: Sanjay Dhand > Cc: SIP Mailing List > Subject: Re: [Sip] Authentication: qop/cnonce issue > > > Going through old emails. > > As far as I can tell, this appears as yet another bug in rfc2617. I > suspect the proper solution is that you can only use MD5-sess > if a qop > directive is issued. > > -Jonathan R. > > Sanjay Dhand wrote: > > > Hi All, > > > > I have a query regarding "qop" and "cnonce" fields in Digest > > Authentication procedure. Looks like some gap in the specs. Please > > provide your input. > > > > The problem is that if qop parameter does not arrive in > the Challenge > (401/407) and the algo for the session is "MD5-sess" then > Hash Key A1 is > built with "cnonce-value" at the client, but "cnonce-value" > is not sent > to the Server in the subsquent Requests. > > > > Then How will the Server decode the response without the > "cnonce-value"? > > > > Does it mean that if Algo is "MD5-Sess", then qop > parameter MUST be > supplied to the client in the Challenge? > > > > Quoted from RFC 2617, Sec 3.2.2: > > > > "If qop (Quality of Protection) is not sent to the Client > then cnonce > > value and nonce-count value MUST NOT be specified in the > subsquents > > requests." > > > > AND (construction of the Hash Key A1) > > > > If Algo is "MD5-sess" then A1 is calculated as > > A1 =H(unq(username-value) ":" unq(realm-value) ":" passwd ":" > > unq(nonce-value) ":" unq(cnonce-value) > > > > where A1 is the Session Key for authentication of > subsquent requests and > > responses. > > > > A1 is used to calculate the response-digest along with the > second hash > > Key A2. > > > > Best regards, > > > > Sanjay Dhand > > > > ipDialog India Pvt Ltd > > 453, Udyog Vihar phase 5, > > Gurgaon INDIA. > > > > ph: (91) (120) 6399051, 6399657/58 > > cell: 9810309914 > > > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 08:08:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20066 for ; Tue, 8 Jan 2002 08:08:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA27969 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 08:08:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27277; Tue, 8 Jan 2002 07:49:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27249 for ; Tue, 8 Jan 2002 07:49:13 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19931 for ; Tue, 8 Jan 2002 07:49:11 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 07:48:41 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE460A3EC9@ftmail> From: "Alan O'Neill" To: William Marshall , sip@ietf.org Subject: RE: [Sip] Still issues with preconditions Date: Tue, 8 Jan 2002 07:48:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for the response Bill Comments in-line -----Original Message----- From: William Marshall [mailto:wtm@research.att.com] Sent: 27 December 2001 17:16 To: sip@ietf.org Subject: Re: [Sip] Still issues with preconditions Alan O'Neill raised a question about the manyfolks draft after the end of the last call discussion. The question basically is about choice of resources when both UAC and UAS perform bi-directional reservation. AWO> My questions were specifically about the problems/limitations caused by the overloading of the strength-tag, the combined sendrecv direction-tag and the ambiguity in the processing caused by the protocol not actually resolving lead roles (ie who should attempt to book resources). The example of both ends being capable of bi-directional reservations is one case in which problems are exposed but is by no means the worst case as I'll explain later. While I addressed this in my presentation at IETF52, a response to the list was requested. AWO> This is appreciated Bill as I was not able to get to the IETF due to my newborn son. This situation occurs in the following sequence. The UAC sends an INVITE with a preconcition line in the SDP "a=qos:sendrecv mandatory" The UAS responds with "a=qos: sendrecv mandatory confirm" Both the UAC and UAS attempt to reserve resources, both of which perform bi-directional reservations, both of which succeed. The draft is perfectly clear about the need of both the UAS and UAC to attempt to make the reservations, but not clear on whose resources should be used. AWO> the example is clear on that issue but the draft also says that resources can be booked either in series or in parallel in specific circumstances - hence ambiguity about when parallel and serial can or should be used... The proposal from Flarion adds significant complexity in initial SDP contents indicating the resource reservation capabilities of the UA, and the existance of any pre-existing resources, so that this double reservation can be avoided. AWO> It is one new tag which is hardly 'significant complexity' Bill and that new tag solves a number of issues, not just the specific case presently being discussed of both ends with bi-directional capability. The ambiguity in the sendrecv direction-tag and the overloaded strength tag leads to 'impossible' preconditions not being detected until after a significant amount of signalling (COMET). I think the worse case would be a sendrecv precondition when both ends have opposite unidirectional capabilities..discussed later. This situation can be resolved very simply by the entity receiving the COMET (typically the UAS). Certain resources are identified in the COMET, and the UAS merges those with its locally-reserved resources. Any overlap is detected by the UAS, and redundant resources should be released by the UAS. I'll add a sentence to that affect. AWO> Well this eventually solves the double booking but is clearly very unfortunate and a somewhat cumbersome process I think you would agree. There is certainly a problem when resources exist for only one call, and both the UAC and UAS attempt (and fail) to reserve them. This is commonly called glare, and is a variation of the classical dining philosopher problem. The solution is complex, is not handled in the current draft, and (I propose) should stay that way. AWO> Flarion develops technology for cellular basestations where each cell typically has a small number of voice call slots so this overbooking is very unwelcome both to us and I would suspect also to 3G solutions. The problem is I am sure you agree greatly reduced with the information processing I have previously outlined. What is clearly needed is a means to signal an endpoints capabilities. This is only possible by separating the direction-tag so that send and receive direction capabilities can be uniquely signalled (this split is needed and used in the COMET for the same reasons but is often too late to avoid wasted signalling for impossible preconditions). Then the result-tag (removing the overloading of the strength-tag) associated with a direction-tag can now inform an endpoint of the other ends capabilities immediately in the offer. The example under discussion of endpoints with bi-directional capabilities is not the only nor main reason to do this. Take the case where the precondition can not possiblly be met. Now the earlier either end can determine this then the better because any signalling is simply wasted (a particularly bad situation for bandwidth constrained access such as cellular). Clearly signalling offerer capabilities enables the receiver of the SDP to immediately detect impossible preconditions and to rapidly refuse the call, minimising wasted signalling and the duration of held and hence wasted resources. If the receiver doesn't detect the impossible precondition then its answer will enable the sender to so detect. Only QoS signalling failures due to resource constraints or equipment problems can then produce preconditions that ultimately fail after a significant amount of signalling exchanges occur... The other point raised by Alan is more up for discussion. Resource reservation can logically be divided into segments between the UAC and UAS, and there are different ways to partition the problem. Consider the following diagram: /-1-<<-2-<<-3-\ A B \-4->>-5->>-6-/ While systems can certainly obtain QoS prior to sending the INVITE, that leads to a vertical partitioning (the so-called segmented qos model). AWO> Not necessarily so. Existing resources can also exist in the horizontal model. The resources can be pre-signalled with RSVP for a hot-line application during emergencies for example and then the SDP could be sent informing the other end that the resources already exist leading to rapid call set-up. Another example is call-waiting via a media gateway shared by the existing and new call such that the resources again exist. Making any assumption about how QOS is actually done or where the mechanism will be useful to operators is a dangerous game. The SDP preconditions mechanism should simply provide a means for user to exchange best guesses on resource availability given their QoS protocols, SLAs and other configuration. UA #A can ensure QoS in segments 1&4, UA #B ensures 3&6, and both assume diffserv for 2&5. This scenario can certainly be optimized. AWO> This is a common case in IP backbone networks where the operators have dimensioned the core and the access is constrained. There are other models in the enterprise where the resource dumbell is reversed such that the access is plentiful and the core constrained. Essentially though, if the user via the operator SLA knows that it only needs to deal with the access then a 'general' SDP preconditions signalling capability should be able to deal with it in my book. Why overload tags when we can be clear and clean, and still be open to future enhancements to the interactions between QoS protocols and SDP preconditions. If you would be happy to modify the tag structures as suggested then I would be more than happy to take the wider scope of the preconditions signalling into a new draft and progress that as a future enhancement to SDP preconditions. This cannot be done though unless the tags are redesigned or a parallel set of tags and processes developed which I think none of us would wish...I hope you can see that The manyfolks draft assumes a horizontal partitioning, and only includes syntactic mechanism to describe the 1&2&3 combination (A:recvonly) and the 4&5&6 (A:sendonly). AWO> Well that assumption should be stated clearly because it claimed to be all embracing when it clearly is not. Thats fine but if it is not all embracing then the mechanism should be designed to enable other models to be supported from future drafts. However, even with your horizontal model you have a number of problems to adddress. The horizontal model assumes admission control and resource booking on all segments on the paths 123 and 456. Lets take RSVP..now what are you going to do if the RSVP reports a non-RSVP cloud ? You could go either way but ultimately the only reasonable thing to do depends on the assurance given to the user by the operator for its QoS mechanisms. Another example would be an operator using aggregate RSVP over a diff-serv backbone with statistical overbooking. Is this good enough to enable a user to meet the horizontal assumption or not, clearly it depends on the degree of overbooking which is directly related to the level of assurance given by the oeprator for there QoS mechanisms and should be reflected in the associated settings for its users hosts when processing SDP preconditions. The vertical and horizontal models are in summary far to simple to be real and meaningful and certainly do not represent either the present or future limits of what will be done. Therefore, we must disassociate these models from the SDP preconditions signalling and trust the users application to do the right thing given knowledge from its operator via config or policy.... Should additional terms be defined in manyfolks draft, such as "access" and "backbone" to enable this vertical split? Second, are these the right terms? Comments? AWO> In all cases, the user software should be aware of how it can respond to offered preconditions given its QoS capabilities and its SLA with its operator. This response should be outside the preconditions draft and should instead be in a document discussing the mapping between preconditions and network QoS mechanisms and topologies. The draft should continue to include the simplified horizontal example whilst these mappings are agreed in my book... Including success of preconditions without knowing the destination seems to require a crystal ball. Good topic for a separate I-D. AWO> Exactly, but you are equally assuming a crystal ball becasue you are also assuming that the horizontal model has undertaken node by node admission control and resource booking which I doubt many networks will ever support. I hope you can see the problem with the assumptions about QoS protocols and operator, inter-operator models....and the need to separate preconditions signalling from these assumptions in this draft... And, just for the record, Alan O'Neill wrote: > ... I have tried to > raise / resolve issues with the authors of the draft but have so far not had > any response. First I heard of this issue was email on Monday 10 December, and actually read the message from Rakesh first, also 10 December, which stated the status of manyfolks draft was "Looking at some late comments" AWO> Well then Bill I apologise if my e-mails were not received by you. I certainly made a couple of attempts to reach you privately and also had no feedback from my e-mails to the list till now. I greatly appreciate your response and hope we can reach concensus on this quickly so that the draft can progress.. AWO> Please consider my suggestion for redesigning the tags to be more general and then limiting the scope of your draft to the simple horizontal case with no pre-booked resources or capabilities exchange. Your draft can then progress rapidly whilst we write up the extensions in a new draft to support capabilites exchange and lead role negotiation, and to also address the vertical model. We can then take requirements from operators/vendors on the appropriate behaviour for a node given its QoS capability and SLA, and then turn this into a future mapping draft so that all internet nodes can process preconditions consistently within an agreed broad framework. I hope that is a reasonable and useful suggestion to you and your co-authors. Regards, Alan O'Neill Flarion Technologies (www.flarion.com) -----original message----- From: "Alan O'Neill" To: "'sip@ietf.org'" Date: Mon, 10 Dec 2001 03:06:27 -0500 Subject: [Sip] Still issues with preconditions Version 3 of the manyfolks-resources draft has appeared but there still appear to me to be a number of issues with this document. I have tried to raise / resolve issues with the authors of the draft but have so far not had any response. In summary; i) The strength-tag appears overloaded in attempting to carry both requirement (Mandatory/Optional) and progress (Success/Failure) information. This prevents a node with precondition resources already in place (existing resources in call waiting / dimensioned diff-serv QoS) from including the Success progress in an Invite which in the general case would lead to very fast and efficient call set-up. In the case of incapability, the caller could signal the inability to meet a precondition direction itself with a Failure which would enable the callee to immediately and quickly detect impossible preconditions when merged with its own incapabilities. The limitation of the overloaded strength-tag could be avoided by using an additional result-tag in each precondition to signal progress separately from the requirement in the strength-tag. ii) The draft is clear on the negotiation phases of the precondition signalling and how direction-tags in requests, responses and COMETs are related. However, it is not at all clear how end nodes actually work out how to respond to offered preconditions and how they work out which resources each end should attempt to meet, especially regarding whether preconditions must/may/must not be attempted in parallel or in series at the caller and callee. This ambiguity is clearly a barrier to the production of multiple interworking implementations and leads to inefficient call set-up and cleardown, as well as the danger of each end trying to book the same resources. I'll use a brief and specific example in an attempt to get some discussion on the second issue which is maybe less obvious than the first... In the first example in the draft, the caller requests a sendrecv resource precondition and includes a confirmation request. The callee cannot tell if the caller is able or wishes to meet either send or recv direction in the sendrecv precondition, only that it wishes to be informed of progress. The callee responds with sendrecv confirm but the caller cannot glean any information from the inclusion of the confirm by the callee. This is because the callee confirmation request is mandated in the draft in response to the caller confirmation request. The only information exchanged (that I can glean from the draft) so far is that the callee, in accepting the sendrecv precondition, is informing the caller that it can contribute in some way to meeting the sendrecv precondition. The caller now sends a PRACK and repeats the precondition it sent in the Invite. At this point, the example says that both the caller and callee can in parallel start booking resources to meet the sendrecv precondition but this opens up the possibility of problems because neither end has actually agreed with the other end on which of the precondition directions it is going to attempt (ie lead roles in meeting preconditions). The model only works if both ends have the same unidirectional reservation capability (send only or recv only) such that non-overlapping resources are booked. If both ends can book both directions (sendrecv) then full duplication is possible (double the resources). If both ends have opposite capabilities (caller send/recv and callee recv/send) then one direction will get double the resources and the other will have no resources booked. The double / missing resources will always be detected by the caller because the callee COMET will include success/failure separately for each direction so that the caller can recover, but clearly the caller can only then change its reservation status because no mechanism exists to get the callee to do so. The existance of duplicate reservations is clearly unfortunate and could be avoided if the preconditions negotiation was explicit about agreeing which resources each end should attempt to reserve. I hope one of the authors will be kind enough to help me with this.... Regards, Alan O'Neill ---------------------------------------------------------------- Notice Regarding Intellectual Property Rights Flarion's submissions will conform with RFC 2026. Flarion may seek patent protection on some or all of the technical information submitted by its employees in connection with the IETF's standards process. If part(s) of a submission by Flarion is (are) included in a standard and Flarion owns patent(s) and/or pending patent application(s) that are essential to implementation of such included part(s) in said standard, Flarion is prepared to grant a license on fair, reasonable, reciprocal (license back) and non-discriminatory terms on such included part(s). _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 08:09:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20087 for ; Tue, 8 Jan 2002 08:09:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28003 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 08:09:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27322; Tue, 8 Jan 2002 07:49:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27286 for ; Tue, 8 Jan 2002 07:49:21 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19933 for ; Tue, 8 Jan 2002 07:49:19 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 07:48:49 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE460A3ECA@ftmail> From: "Alan O'Neill" To: Brian Williams Cc: sip@ietf.org Subject: RE: [Sip] Still issues with preconditions Date: Tue, 8 Jan 2002 07:48:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello Brian, Please see my previous note to Bill which I think covers my views on your points.. I'd specifically appreciate your perspectives on my points on resource booking and wasted signalling in the context of 3G access if that is your poison :-) Nothing in-line.. Thanks, Alan. -----Original Message----- From: Brian Williams [mailto:brian.williams@ericsson.com.au] Sent: 29 December 2001 12:36 To: William Marshall Cc: sip@ietf.org Subject: Re: [Sip] Still issues with preconditions Hi All. On Fri, 2001-12-28 at 04:16, William Marshall wrote: : : > The other point raised by Alan is more up for discussion. > > Resource reservation can logically be divided into segments between > the UAC and UAS, and there are different ways to partition the problem. > > Consider the following diagram: > /-1-<<-2-<<-3-\ > A B > \-4->>-5->>-6-/ > > While systems can certainly obtain QoS prior to sending the INVITE, that > leads to a vertical partitioning (the so-called segmented qos model). > UA #A can ensure QoS in segments 1&4, UA #B ensures 3&6, and both assume > diffserv for 2&5. This scenario can certainly be optimized. > > The manyfolks draft assumes a horizontal partitioning, and only includes > syntactic mechanism to describe the 1&2&3 combination (A:recvonly) and the > 4&5&6 (A:sendonly). The draft specifies that resource reservation takes place using whatever protocols the participants must use. Therefore, the precondition mechanism must not be dependent on any specific "partitioning" of the QoS controls. I believe the solution is not actually dependent on any particular partitioning, but the explanatory text certainly focuses on the horizontal partitioning indicated. > Should additional terms be defined in manyfolks draft, such as "access" > and "backbone" to enable this vertical split? Second, are these the > right terms? Comments? The preconditions mechanism provides a general means to co-ordinate the call session with other aspects. Although it does specify the preconditions to be met, the manyfolks draft does not consider any details of the actual mechanisms used to meet the preconditions. From this perspective, manyfolks should not need to identify many different QoS scenarios which require different behaviours. Rather, the draft should simply be clear that each participant believes that they have met the QoS pre-conditions they have indicated. This may simply require some clarification of the wording to ensure that each participant does evaluate its own view of the QoS conditions when merging with the remote participants conditions. /brian > > Including success of preconditions without knowing the destination seems > to require a crystal ball. Good topic for a separate I-D. > > And, just for the record, > > Alan O'Neill wrote: > > ... I have tried to > > raise / resolve issues with the authors of the draft but have so far not had > > any response. > > First I heard of this issue was email on Monday 10 December, and actually read > the message from Rakesh first, also 10 December, which stated the status of manyfolks > draft was "Looking at some late comments" > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Alan O'Neill" > To: "'sip@ietf.org'" > Date: Mon, 10 Dec 2001 03:06:27 -0500 > Subject: [Sip] Still issues with preconditions > > Version 3 of the manyfolks-resources draft has appeared but there still > appear to me to be a number of issues with this document. I have tried to > raise / resolve issues with the authors of the draft but have so far not had > any response. > > In summary; > > i) The strength-tag appears overloaded in attempting to carry both > requirement (Mandatory/Optional) and progress (Success/Failure) information. > This prevents a node with precondition resources already in place (existing > resources in call waiting / dimensioned diff-serv QoS) from including the > Success progress in an Invite which in the general case would lead to very > fast and efficient call set-up. In the case of incapability, the caller > could signal the inability to meet a precondition direction itself with a > Failure which would enable the callee to immediately and quickly detect > impossible preconditions when merged with its own incapabilities. The > limitation of the overloaded strength-tag could be avoided by using an > additional result-tag in each precondition to signal progress separately > from the requirement in the strength-tag. > > ii) The draft is clear on the negotiation phases of the precondition > signalling and how direction-tags in requests, responses and COMETs are > related. However, it is not at all clear how end nodes actually work out how > to respond to offered preconditions and how they work out which resources > each end should attempt to meet, especially regarding whether preconditions > must/may/must not be attempted in parallel or in series at the caller and > callee. This ambiguity is clearly a barrier to the production of multiple > interworking implementations and leads to inefficient call set-up and > cleardown, as well as the danger of each end trying to book the same > resources. > > > I'll use a brief and specific example in an attempt to get some discussion > on the second issue which is maybe less obvious than the first... > > In the first example in the draft, the caller requests a sendrecv resource > precondition and includes a confirmation request. The callee cannot tell if > the caller is able or wishes to meet either send or recv direction in the > sendrecv precondition, only that it wishes to be informed of progress. The > callee responds with sendrecv confirm but the caller cannot glean any > information from the inclusion of the confirm by the callee. This is because > the callee confirmation request is mandated in the draft in response to the > caller confirmation request. The only information exchanged (that I can > glean from the draft) so far is that the callee, in accepting the sendrecv > precondition, is informing the caller that it can contribute in some way to > meeting the sendrecv precondition. > > The caller now sends a PRACK and repeats the precondition it sent in the > Invite. At this point, the example says that both the caller and callee can > in parallel start booking resources to meet the sendrecv precondition but > this opens up the possibility of problems because neither end has actually > agreed with the other end on which of the precondition directions it is > going to attempt (ie lead roles in meeting preconditions). The model only > works if both ends have the same unidirectional reservation capability (send > only or recv only) such that non-overlapping resources are booked. If both > ends can book both directions (sendrecv) then full duplication is possible > (double the resources). If both ends have opposite capabilities (caller > send/recv and callee recv/send) then one direction will get double the > resources and the other will have no resources booked. The double / missing > resources will always be detected by the caller because the callee COMET > will include success/failure separately for each direction so that the > caller can recover, but clearly the caller can only then change its > reservation status because no mechanism exists to get the callee to do so. > The existance of duplicate reservations is clearly unfortunate and could be > avoided if the preconditions negotiation was explicit about agreeing which > resources each end should attempt to reserve. > > I hope one of the authors will be kind enough to help me with this.... > > Regards, Alan O'Neill > > ---------------------------------------------------------------- > Notice Regarding Intellectual Property Rights > > Flarion's submissions will conform with RFC 2026. Flarion may seek patent > protection on some or all of the technical information submitted by its > employees in connection with the IETF's standards process. If part(s) of a > submission by Flarion is (are) included in a standard and Flarion owns > patent(s) and/or pending patent application(s) that are essential to > implementation of such included part(s) in said standard, Flarion is > prepared to grant a license on fair, reasonable, reciprocal (license back) > and non-discriminatory terms on such included part(s). > > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 08:35:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20303 for ; Tue, 8 Jan 2002 08:35:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA28948 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 08:35:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28235; Tue, 8 Jan 2002 08:20:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA28206 for ; Tue, 8 Jan 2002 08:20:28 -0500 (EST) Received: from hssblrmail.hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20183 for ; Tue, 8 Jan 2002 08:20:21 -0500 (EST) From: seshashayi@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hssblrmail.hss.hns.com (8.11.2/8.11.2) with SMTP id g08D9b914947; Tue, 8 Jan 2002 18:39:37 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B3B.00486991 ; Tue, 8 Jan 2002 18:40:56 +0530 X-Lotus-FromDomain: HSSBLR To: Jonathan Rosenberg , sip@ietf.org Message-ID: <65256B3B.004868DF.00@sampark.hss.hns.com> Date: Tue, 8 Jan 2002 18:40:54 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Authentication-Info ABNF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, The bis-05 mentions that the Syntax and semantics of Authentication-info header follow those specified in the RFC2617. (bis05-Lineno:3454) But,in the section on BNF, it gives the grammar from RFC2609. (bis05-Lineno:4521) And RFC2617 is supposed to obselete RFC2609. Can anyone clarify as to which BNF is to be followed? Thanks Seshu _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 09:23:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22724 for ; Tue, 8 Jan 2002 09:23:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA00970 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 09:23:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00161; Tue, 8 Jan 2002 09:01:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00128 for ; Tue, 8 Jan 2002 09:01:53 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21740; Tue, 8 Jan 2002 09:01:53 -0500 (EST) Message-Id: <200201081401.JAA21740@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Jan 2002 09:01:52 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-srv-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --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 : SIP: Locating SIP Servers Author(s) : H. Schulzrinne, J. Rosenberg Filename : draft-ietf-sip-srv-03.txt Pages : 11 Date : 07-Jan-02 The Session Initiation Protocol (SIP) makes use of DNS procedures to allow a client to resolve a SIP URI into the IP address, port, and transport of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client in the event of a failure of the primary client. This document describes those DNS pro- cedures in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-srv-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-srv-03.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-srv-03.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: <20020107135559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-srv-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-srv-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020107135559.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 09:44:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23740 for ; Tue, 8 Jan 2002 09:44:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02401 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 09:44:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01546; Tue, 8 Jan 2002 09:29:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01515 for ; Tue, 8 Jan 2002 09:29:43 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23104 for ; Tue, 8 Jan 2002 09:29:40 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08ETgVZ009313; Tue, 8 Jan 2002 09:29:42 -0500 (EST) Message-ID: <3C3B0237.30206@dynamicsoft.com> Date: Tue, 08 Jan 2002 09:29:11 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org Subject: Re: [Sip] Issue #364: correlation problems References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > It seems like a generally bad thing that we do not have a way to > correlate a > SSRC in a RTP stream with the media stream in the SDP that it relates > to. > Similarly it should be easier to correlate media stream in SDP from one > transaction to the next (fid please?). The endlessly growing SDP is, ah, > ugly. > > If we solved our RTP <-> SDP <-> dialog correlation problems - would > Issue > 364 go away? I don't think so. There seem to be sufficient other problems for which people want to use a three-way handshake that its still an issue. I am in the process of collecting the various problems people are trying to solve in order to figure this one out properly. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 09:48:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23939 for ; Tue, 8 Jan 2002 09:48:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02463 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 09:48:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01436; Tue, 8 Jan 2002 09:27:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01291 for ; Tue, 8 Jan 2002 09:27:34 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23029 for ; Tue, 8 Jan 2002 09:27:33 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08ERPVZ009310; Tue, 8 Jan 2002 09:27:26 -0500 (EST) Message-ID: <3C3B01AE.2050008@dynamicsoft.com> Date: Tue, 08 Jan 2002 09:26:54 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: seshashayi@hss.hns.com CC: sip@ietf.org Subject: Re: [Sip] Authentication-Info ABNF References: <65256B3B.004868DF.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It should be the rfc2617 grammar. We'll fix. Thanks, Jonathan R. seshashayi@hss.hns.com wrote: > > Hi, > The bis-05 mentions that the Syntax and semantics of > Authentication-info > header > follow those specified in the RFC2617. (bis05-Lineno:3454) > But,in the section on BNF, it gives the grammar from RFC2609. > (bis05-Lineno:4521) > And RFC2617 is supposed to obselete RFC2609. > > Can anyone clarify as to which BNF is to be followed? > Thanks > Seshu > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 09:58:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24342 for ; Tue, 8 Jan 2002 09:58:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02642 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 09:58:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02367; Tue, 8 Jan 2002 09:43:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02331 for ; Tue, 8 Jan 2002 09:43:36 -0500 (EST) Received: from hotsip.com ([212.28.214.249]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23697 for ; Tue, 8 Jan 2002 09:43:34 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 8 Jan 2002 15:43:01 +0100 Message-ID: Thread-Topic: Comments and suggestions to draft-ietf-sip-nat-01.txt Thread-Index: AcGYVD8Hbm/zxJD8RL6IjKPropKwsQ== From: "Kristoffer Gronowski" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA02332 Subject: [Sip] Comments and suggestions to draft-ietf-sip-nat-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi! We have implemented the draft on our SIP server and client and I have some reflections and suggestions to propose. Section 3 "For INVITE transactions, the client may need to retransmit its INVITE every 20 seconds or so, even after receiving a provisional response, in order to keep the binding open to receive the final response." Should a retransmit value smaller then 32 seconds (11 retransmissions) be permitted? This would encourage clients to send requests to often and possibly flood the system! It might be OK to do it more often if a 2xx response is received. Section 4. Translate header is sent back to client. Is this really necessary? The bottom Via contain both the white and black IP addresses and ports? The reason for this is that we want to minimize the packet sizes for sip messages and not send redundant data. (In the GPRS case the client is often on a NAT network with limited uplink capabilities.) We have tried to solve the firewall problem with the same approach. Since the majority of the firewalls has statful inspection. Then the state can be kept alive with the same approach. The UA has to send a SIP message frequently enough. A firewall can be seen as a symmetrical NAT without the address translation part. This makes it more difficult to detect. One simple solution is that the UA lets the end user to specify if behind FW or not. For a more complex UA the probing approach with sending OPTIONS SIP message can be used. One of the biggest concerns is that the record routing in the proxy is fairly expensive operation. A suggestion is to tag the contact with the nat=sym parameter and only record route those requests. This will solve both the tricky NAT's and stateful inspection firewalls! REGISTER sip:ua2@Y.com SIP/2.0 From: sip:ua2@Y.com To: sip:ua2@Y.com Via: SIP/2.0/UDP 10.0.1.100;rport Translate: sip:ua2@10.0.1.100:2234;nat=sym Contact: sip:ua2@10.0.1.100:2234 SIP/2.0 200 OK From: sip:ua2@Y.com To: sip:ua2@Y.com Via: SIP/2.0/UDP 10.0.1.100;rport=2397;received=77.2.3.88 Contact: sip:ua2@77.2.3.88:2397;nat=sym To put the NAT parameter on the contact feels quite natural since it describes the contacts property and routing essential information. Another recommendation should be to check all the final responses sent from the server to the UA. The Via header black and white addresses should be compared with the once that the UA is believed to have. This is due to the fact that a NAT can change the used white port at given times. The UA should detect this and refresh it's registration so that other UA can find it! If the UA can handle presence the SUBSCRIBE SIP messages have to be refreshed as well! The last issue is if this draft should contain solutions for the IM and presence extension so that they can handle NAT's? Regards Kristoffer! Kristoffer Gronowski Sen. Software Developer Hotsip AB mailto: kristoffer.gronowski@hotsip.com sip: stoffe@hotsip.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 10:36:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25857 for ; Tue, 8 Jan 2002 10:36:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04263 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 10:36:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03486; Tue, 8 Jan 2002 10:15:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03455 for ; Tue, 8 Jan 2002 10:15:25 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24953 for ; Tue, 8 Jan 2002 10:15:23 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA14732 for ; Tue, 8 Jan 2002 10:15:25 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g08FFPJ1011070 for ; Tue, 8 Jan 2002 10:15:25 -0500 (EST) Message-ID: <3C3B0D0D.72028639@cs.columbia.edu> Date: Tue, 08 Jan 2002 10:15:25 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 3G dependencies Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit http://www.3gpp.org/TB/Other/IETF.htm -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 10:37:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25902 for ; Tue, 8 Jan 2002 10:37:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04297 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 10:37:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03391; Tue, 8 Jan 2002 10:12:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03282 for ; Tue, 8 Jan 2002 10:11:54 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24845 for ; Tue, 8 Jan 2002 10:11:53 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g08FBNt03293; Tue, 8 Jan 2002 10:11:23 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g08FBKF02055; Tue, 8 Jan 2002 10:11:21 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 10:09:47 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102ADEF@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 10:10:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19856.922BADB0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19856.922BADB0 Content-Type: text/plain; charset="iso-8859-1" A long time since I looked at that code, but I seem to recall a timeout after three minutes of ringing on the DMS. -----Original Message----- From: William Marshall [mailto:wtm@research.att.com] Sent: Monday, January 07, 2002 10:12 PM To: sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) In the circuit switch world, the equivalent of "Timer C" exists. On a 5ESS, ringback turns to fast busy after 3 minutes. On a 4ESS, it happens after 90 seconds. (Both figures were as of a few years ago, but I doubt they have changed). Perhaps someone from Nortel could speak of the DMS switches. Also as of a few years ago, business customers paid for ring time, so if still true, it is not clear why AA is "cheating". So a timeout value of a couple of minutes (like 4) would work just fine for calls into the PSTN, and would only get hit for a high-and-dry type of defect. Bill Marshall wtm@research.att.com -----original message----- From: John.Hearty@Level3.com Subject: RE: [Sip] Default value for Timer C (was #282) Date: Mon, 7 Jan 2002 15:56:14 -0700 I agree with Bob. AA is apparently cheating here, doing all their IVR functions without returning answer. I vote for the alternative, choosing a value on the order of minutes (not more than maybey three or four). John Hearty Level3 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, January 07, 2002 3:33 PM To: Bob Penfield Cc: Henry Sinnreich; 'Robert Sparks'; sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) This thread has stalled, and I think it requires some further input before we can resolve it. The issue was this: what minimum timer do we mandate for a proxy to hang onto invite transaction state after receiving 1xx? The issue is that some PSTN systems (american airlines in particular), appear to use early media while a user is on hold waiting, or using the DTMF based IVR system. The result is that a call from a PC to a PSTN number could, in theory go legitimately unanswered for hours, perhaps. This would require that Timer C in proxies be on the order of hours, which is quite large. An alternative is to not consider this case, and choose a smaller value, on the order of minutes. Both can result in DoS attacks, although in this case, the proxy shouldn't be storing transaction state for unauthenticated requests. Determining whether or not to go with a large value depends a lot on how common such systems are in the PSTN, and what the expectation is for them to be properly supported. Further inputs? -Jonathan R. Bob Penfield wrote: >>>I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>> > > The same problem occurs using old-world TDM equipment. If I use my > calling > card account to call AA, it hangs up after about a minute because the > calling card platform has a 60 second answer timer. AA is trying to save > money by having their ACD not return an answer and thus they don't have > to > pay for the 800 call. > > BTW, all billing is based on answer (2xx for SIP) being returned by the > called party. Some systems (usually in hotels) do use a timer when > answer > cannot be determined reliably (or they don't care). > > I'm curious as to whether this was isolated to a proxy or is it possible > the > TDM side of the gateway is dropping the call? If gateways have answer > timers > on this order of magnitude, having a really long timer in the proxy > won't > help. > > In any event, do we really need to support these cheaters in SIP and > open > ourselves to DOS attacks? > > >>I have exactly the same experience. >>As for: >> >> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, >>> >>I don't know how to tweak to and I don't ever want to know. >> >>Is there a better approach to fix the timer value or am I missing >>something? >> >>Thanks, Henry >> >> >>>-----Original Message----- >>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of >>> >>Robert >> >>>Sparks >>>Sent: Thursday, December 27, 2001 9:57 AM >>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks >>>Cc: sip@ietf.org >>>Subject: [Sip] Default value for Timer C (was #282) >>> >>>I'm talking about a _real problem_ that I have >>>_right now_ with the UAs on my desk and the gateways >>>I have access to. I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>>Try it - call +18004337300 - my environment drops the unanswered >>>call about 58 seconds into the first menu (yes, the first menu >>>is over a minute long). >>> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, I could >>>work around it. But what about my tweak-phobic aquaintances >>>and relatives? >>> >>>In this case, the endpoints are dropping the call, but if I had >>>otherwise behaving endpoints, and a proxy in the middle with a >>>_default_ Timer C value that is too small, I am left with >>>at least one well-known service that just doesn't work. >>> >>>Now, we could get into a discussion about whether or not a service >>>_should_ run a whole bunch of time in an early media state, but >>>that's rather moot - we've worked really hard to make the system >>>allow it, and it will be used. We're here on purpose, not by >>>misfortune of oversight. >>> >>>As for your last paragraph - who says early media has to be free? >>> >>>RjS >>> >>> >>> >>>>From: Bob Penfield [mailto:bpenfield@acmepacket.com] >>>> >>>>>>If this is acceptable, it still leaves us with the question >>>>>>of what value we should recommend. I propose something >>>>>>long - order of .5 to 1 hour (remember that calls stay in a >>>>>>provisional state with early media when you are in the queue >>>>>>to talk to an AA representative). >>>>>> >>>>> >>>>>Egads, thats a long time! Your point on early media is well >>>>> > taken, > >>>>>though. Arguably, if this case happens, 1 hour is not even >>>>> >>>>enough, since >>>> >>>>>I have certainly been on hold for durations longer than >>>>> >>>>that. Probably 4 >>>> >>>>>hours is more reasonable. Once you've set the timer this >>>>> >>>>high, it may as >>>> >>>>>well be any finite number as far as the proxy is concerned. The >>>>> >>only >> >>>>>value in having a number at all (as opposed to infinity) is >>>>> >>>>very long >>>> >>>>>term garbage collection. You will get NO DoS attack prevention >>>>> >>from >> >>>>>numbers of this magnitude. You really need to be careful, >>>>> >>>>as a proxy, to >>>> >>>>>not create transaction state unless the request is >>>>> >>>>authenticated somehow. >>>> >>>>I don't think this really applies. I believe that most ACD >>>>systems that put >>>>you on hold actually do answer the call. Especially ones that >>>>have DTMF >>>>menus since some carriers block the caller to callee >>>>connection until it is >>>>answered. Many TDM switches that I have experience with will >>>>tear down an >>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3 >>>>minute timer >>>>would be adequate. >>>> >>>>But, this is not the TDM world. So, if we want to provide for >>>>unanswered >>>>calls being queued for long periods of time, maybe we could >>>>require the UAS >>>>to send periodic provisional responses and the proxy could >>>>reset Timer C. >>>>But that may be getting to complicated. >>>> >>>>Service providers who charge for these calls don't want their >>>>resources used >>>>for free for such a long period of time. >>>> >>>>cheers, >>>>(-:bob >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of >>>> > sip > >>>_______________________________________________ >>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C19856.922BADB0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Default value for Timer C (was #282)

A long time since I looked at that code, but I seem to recall a timeout after three minutes of ringing on the DMS.

-----Original Message-----
From: William Marshall [mailto:wtm@research.att.com]
Sent: Monday, January 07, 2002 10:12 PM
To: sip@ietf.org
Subject: Re: [Sip] Default value for Timer C (was #282)


In the circuit switch world, the equivalent of "Timer C" exists.
On a 5ESS, ringback turns to fast busy after 3 minutes.  On a 4ESS,
it happens after 90 seconds.  (Both figures were as of a few years
ago, but I doubt they have changed).  Perhaps someone from Nortel
could speak of the DMS switches.  Also as of a few years ago,
business customers paid for ring time, so if still true, it is not
clear why AA is "cheating".

So a timeout value of a couple of minutes (like 4) would work
just fine for calls into the PSTN, and would only get hit for
a high-and-dry type of defect.

Bill Marshall
wtm@research.att.com

-----original message-----
From: John.Hearty@Level3.com
Subject: RE: [Sip] Default value for Timer C (was #282)
Date: Mon, 7 Jan 2002 15:56:14 -0700

 I agree with Bob.  AA is apparently cheating here, doing all their IVR
functions without returning answer.  I vote for the alternative, choosing a
value on the order of minutes (not more than maybey three or four).

John Hearty
Level3

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, January 07, 2002 3:33 PM
To: Bob Penfield
Cc: Henry Sinnreich; 'Robert Sparks'; sip@ietf.org
Subject: Re: [Sip] Default value for Timer C (was #282)


This thread has stalled, and I think it requires some further input
before we can resolve it.

The issue was this: what minimum timer do we mandate for a proxy to hang
onto invite transaction state after receiving 1xx? The issue is that
some PSTN systems (american airlines in particular), appear to use early
media while a user is on hold waiting, or using the DTMF based IVR
system. The result is that a call from a PC to a PSTN number could, in
theory go legitimately unanswered for hours, perhaps. This would require
that Timer C in proxies be on the order of hours, which is quite large.

An alternative is to not consider this case, and choose a smaller value,
on the order of minutes.

Both can result in DoS attacks, although in this case, the proxy
shouldn't be storing transaction state for unauthenticated requests.

Determining whether or not to go with a large value depends a lot on how
common such systems are in the PSTN, and what the expectation is for
them to be properly supported.

Further inputs?

-Jonathan R.

Bob Penfield wrote:

>>>I have not _ever_ been able to successfully
>>>use my SIP equipment to have a successful dialog with AA.
>>>
>
> The same problem occurs using old-world TDM equipment. If I use my
> calling
> card account to call AA, it hangs up after about a minute because the
> calling card platform has a 60 second answer timer. AA is trying to save
> money by having their ACD not return an answer and thus they don't have
> to
> pay for the 800 call.
>
> BTW, all billing is based on answer (2xx for SIP) being returned by the
> called party. Some systems (usually in hotels) do use a timer when
> answer
> cannot be determined reliably (or they don't care).
>
> I'm curious as to whether this was isolated to a proxy or is it possible
> the
> TDM side of the gateway is dropping the call? If gateways have answer
> timers
> on this order of magnitude, having a really long timer in the proxy
> won't
> help.
>
> In any event, do we really need to support these cheaters in SIP and
> open
> ourselves to DOS attacks?
>
>
>>I have exactly the same experience.
>>As for:
>>
>>
>>>Now, if all the SIP parties involved allowed me to 1) control my
>>>own Expires header, and 2) actually honored the thing,
>>>
>>I don't know how to tweak to and I don't ever want to know.
>>
>>Is there a better approach to fix the timer value or am I missing
>>something?
>>
>>Thanks, Henry
>>
>>
>>>-----Original Message-----
>>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of
>>>
>>Robert
>>
>>>Sparks
>>>Sent: Thursday, December 27, 2001 9:57 AM
>>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks
>>>Cc: sip@ietf.org
>>>Subject: [Sip] Default value for Timer C (was #282)
>>>
>>>I'm talking about a _real problem_ that I have
>>>_right now_ with the UAs on my desk and the gateways
>>>I have access to. I have not _ever_ been able to successfully
>>>use my SIP equipment to have a successful dialog with AA.
>>>Try it - call +18004337300 - my environment drops the unanswered
>>>call about 58 seconds into the first menu (yes, the first menu
>>>is over a minute long).
>>>
>>>Now, if all the SIP parties involved allowed me to 1) control my
>>>own Expires header, and 2) actually honored the thing, I could
>>>work around it. But what about my tweak-phobic aquaintances
>>>and relatives?
>>>
>>>In this case, the endpoints are dropping the call, but if I had
>>>otherwise behaving endpoints, and a proxy in the middle with a
>>>_default_ Timer C value that is too small, I am left with
>>>at least one well-known service that just doesn't work.
>>>
>>>Now, we could get into a discussion about whether or not a service
>>>_should_ run a whole bunch of time in an early media state, but
>>>that's rather moot - we've worked really hard to make the system
>>>allow it, and it will be used. We're here on purpose, not by
>>>misfortune of oversight.
>>>
>>>As for your last paragraph - who says early media has to be free?
>>>
>>>RjS
>>>
>>>
>>>
>>>>From: Bob Penfield [mailto:bpenfield@acmepacket.com]
>>>>
>>>>>>If this is acceptable, it still leaves us with the question
>>>>>>of what value we should recommend. I propose something
>>>>>>long - order of .5 to 1 hour (remember that calls stay in a
>>>>>>provisional state with early media when you are in the queue
>>>>>>to talk to an AA representative).
>>>>>>
>>>>>
>>>>>Egads, thats a long time! Your point on early media is well
>>>>>
> taken,
>
>>>>>though. Arguably, if this case happens, 1 hour is not even
>>>>>
>>>>enough, since
>>>>
>>>>>I have certainly been on hold for durations longer than
>>>>>
>>>>that. Probably 4
>>>>
>>>>>hours is more reasonable. Once you've set the timer this
>>>>>
>>>>high, it may as
>>>>
>>>>>well be any finite number as far as the proxy is concerned. The
>>>>>
>>only
>>
>>>>>value in having a number at all (as opposed to infinity) is
>>>>>
>>>>very long
>>>>
>>>>>term garbage collection. You will get NO DoS attack prevention
>>>>>
>>from
>>
>>>>>numbers of this magnitude. You really need to be careful,
>>>>>
>>>>as a proxy, to
>>>>
>>>>>not create transaction state unless the request is
>>>>>
>>>>authenticated somehow.
>>>>
>>>>I don't think this really applies. I believe that most ACD
>>>>systems that put
>>>>you on hold actually do answer the call. Especially ones that
>>>>have DTMF
>>>>menus since some carriers block the caller to callee
>>>>connection until it is
>>>>answered. Many TDM switches that I have experience with will
>>>>tear down an
>>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3
>>>>minute timer
>>>>would be adequate.
>>>>
>>>>But, this is not the TDM world. So, if we want to provide for
>>>>unanswered
>>>>calls being queued for long periods of time, maybe we could
>>>>require the UAS
>>>>to send periodic provisional responses and the proxy could
>>>>reset Timer C.
>>>>But that may be getting to complicated.
>>>>
>>>>Service providers who charge for these calls don't want their
>>>>resources used
>>>>for free for such a long period of time.
>>>>
>>>>cheers,
>>>>(-:bob
>>>>
>>>>
>>>>_______________________________________________
>>>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>>>This list is for NEW development of the core SIP Protocol
>>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>>Use sipping@ietf.org for new developments on the application of
>>>>
> sip
>
>>>_______________________________________________
>>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol
>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>Use sipping@ietf.org for new developments on the application of sip
>>>
>>
>


--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


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

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

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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_01C19856.922BADB0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 11:09:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27398 for ; Tue, 8 Jan 2002 11:09:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05984 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 11:09:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04427; Tue, 8 Jan 2002 10:37:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04325 for ; Tue, 8 Jan 2002 10:37:49 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25926 for ; Tue, 8 Jan 2002 10:37:47 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id PAA01469; Tue, 8 Jan 2002 15:35:12 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id PAA13956; Tue, 8 Jan 2002 15:37:31 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 08:37:26 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B3710E@n0214idc1.oss.level3.com> To: taylor@nortelnetworks.com, wtm@research.att.com, sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 08:37:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1985A.62E296A0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1985A.62E296A0 Content-Type: text/plain; charset="iso-8859-1" When I worked on the DMS several years ago, the timer was configurable, the company set it for 2 minutes. I'm hearing a general concensus the timer should be in the 1-5 minute range. Perhaps 3 minutes would be agreeable to most. Haven't heard anyone new pipe up for very long times... John Hearty Level3 -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Tuesday, January 08, 2002 8:10 AM To: 'William Marshall'; sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) A long time since I looked at that code, but I seem to recall a timeout after three minutes of ringing on the DMS. -----Original Message----- From: William Marshall [ mailto:wtm@research.att.com ] Sent: Monday, January 07, 2002 10:12 PM To: sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) In the circuit switch world, the equivalent of "Timer C" exists. On a 5ESS, ringback turns to fast busy after 3 minutes. On a 4ESS, it happens after 90 seconds. (Both figures were as of a few years ago, but I doubt they have changed). Perhaps someone from Nortel could speak of the DMS switches. Also as of a few years ago, business customers paid for ring time, so if still true, it is not clear why AA is "cheating". So a timeout value of a couple of minutes (like 4) would work just fine for calls into the PSTN, and would only get hit for a high-and-dry type of defect. Bill Marshall wtm@research.att.com -----original message----- From: John.Hearty@Level3.com Subject: RE: [Sip] Default value for Timer C (was #282) Date: Mon, 7 Jan 2002 15:56:14 -0700 I agree with Bob. AA is apparently cheating here, doing all their IVR functions without returning answer. I vote for the alternative, choosing a value on the order of minutes (not more than maybey three or four). John Hearty Level3 -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Monday, January 07, 2002 3:33 PM To: Bob Penfield Cc: Henry Sinnreich; 'Robert Sparks'; sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) This thread has stalled, and I think it requires some further input before we can resolve it. The issue was this: what minimum timer do we mandate for a proxy to hang onto invite transaction state after receiving 1xx? The issue is that some PSTN systems (american airlines in particular), appear to use early media while a user is on hold waiting, or using the DTMF based IVR system. The result is that a call from a PC to a PSTN number could, in theory go legitimately unanswered for hours, perhaps. This would require that Timer C in proxies be on the order of hours, which is quite large. An alternative is to not consider this case, and choose a smaller value, on the order of minutes. Both can result in DoS attacks, although in this case, the proxy shouldn't be storing transaction state for unauthenticated requests. Determining whether or not to go with a large value depends a lot on how common such systems are in the PSTN, and what the expectation is for them to be properly supported. Further inputs? -Jonathan R. Bob Penfield wrote: >>>I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>> > > The same problem occurs using old-world TDM equipment. If I use my > calling > card account to call AA, it hangs up after about a minute because the > calling card platform has a 60 second answer timer. AA is trying to save > money by having their ACD not return an answer and thus they don't have > to > pay for the 800 call. > > BTW, all billing is based on answer (2xx for SIP) being returned by the > called party. Some systems (usually in hotels) do use a timer when > answer > cannot be determined reliably (or they don't care). > > I'm curious as to whether this was isolated to a proxy or is it possible > the > TDM side of the gateway is dropping the call? If gateways have answer > timers > on this order of magnitude, having a really long timer in the proxy > won't > help. > > In any event, do we really need to support these cheaters in SIP and > open > ourselves to DOS attacks? > > >>I have exactly the same experience. >>As for: >> >> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, >>> >>I don't know how to tweak to and I don't ever want to know. >> >>Is there a better approach to fix the timer value or am I missing >>something? >> >>Thanks, Henry >> >> >>>-----Original Message----- >>>From: sip-admin@ietf.org [ mailto:sip-admin@ietf.org ] On Behalf Of >>> >>Robert >> >>>Sparks >>>Sent: Thursday, December 27, 2001 9:57 AM >>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks >>>Cc: sip@ietf.org >>>Subject: [Sip] Default value for Timer C (was #282) >>> >>>I'm talking about a _real problem_ that I have >>>_right now_ with the UAs on my desk and the gateways >>>I have access to. I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>>Try it - call +18004337300 - my environment drops the unanswered >>>call about 58 seconds into the first menu (yes, the first menu >>>is over a minute long). >>> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, I could >>>work around it. But what about my tweak-phobic aquaintances >>>and relatives? >>> >>>In this case, the endpoints are dropping the call, but if I had >>>otherwise behaving endpoints, and a proxy in the middle with a >>>_default_ Timer C value that is too small, I am left with >>>at least one well-known service that just doesn't work. >>> >>>Now, we could get into a discussion about whether or not a service >>>_should_ run a whole bunch of time in an early media state, but >>>that's rather moot - we've worked really hard to make the system >>>allow it, and it will be used. We're here on purpose, not by >>>misfortune of oversight. >>> >>>As for your last paragraph - who says early media has to be free? >>> >>>RjS >>> >>> >>> >>>>From: Bob Penfield [ mailto:bpenfield@acmepacket.com ] >>>> >>>>>>If this is acceptable, it still leaves us with the question >>>>>>of what value we should recommend. I propose something >>>>>>long - order of .5 to 1 hour (remember that calls stay in a >>>>>>provisional state with early media when you are in the queue >>>>>>to talk to an AA representative). >>>>>> >>>>> >>>>>Egads, thats a long time! Your point on early media is well >>>>> > taken, > >>>>>though. Arguably, if this case happens, 1 hour is not even >>>>> >>>>enough, since >>>> >>>>>I have certainly been on hold for durations longer than >>>>> >>>>that. Probably 4 >>>> >>>>>hours is more reasonable. Once you've set the timer this >>>>> >>>>high, it may as >>>> >>>>>well be any finite number as far as the proxy is concerned. The >>>>> >>only >> >>>>>value in having a number at all (as opposed to infinity) is >>>>> >>>>very long >>>> >>>>>term garbage collection. You will get NO DoS attack prevention >>>>> >>from >> >>>>>numbers of this magnitude. You really need to be careful, >>>>> >>>>as a proxy, to >>>> >>>>>not create transaction state unless the request is >>>>> >>>>authenticated somehow. >>>> >>>>I don't think this really applies. I believe that most ACD >>>>systems that put >>>>you on hold actually do answer the call. Especially ones that >>>>have DTMF >>>>menus since some carriers block the caller to callee >>>>connection until it is >>>>answered. Many TDM switches that I have experience with will >>>>tear down an >>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3 >>>>minute timer >>>>would be adequate. >>>> >>>>But, this is not the TDM world. So, if we want to provide for >>>>unanswered >>>>calls being queued for long periods of time, maybe we could >>>>require the UAS >>>>to send periodic provisional responses and the proxy could >>>>reset Timer C. >>>>But that may be getting to complicated. >>>> >>>>Service providers who charge for these calls don't want their >>>>resources used >>>>for free for such a long period of time. >>>> >>>>cheers, >>>>(-:bob >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of >>>> > sip > >>>_______________________________________________ >>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C1985A.62E296A0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Default value for Timer C (was #282)
When I worked on the DMS several years ago, the timer was configurable, the company set it for 2 minutes.  I'm hearing a general concensus the timer should be in the 1-5 minute range.  Perhaps 3 minutes would be agreeable to most.  Haven't heard anyone new pipe up for very long times...
 
John Hearty
Level3
 
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, January 08, 2002 8:10 AM
To: 'William Marshall'; sip@ietf.org
Subject: RE: [Sip] Default value for Timer C (was #282)

A long time since I looked at that code, but I seem to recall a timeout after three minutes of ringing on the DMS.

-----Original Message-----
From: William Marshall [mailto:wtm@research.att.com]
Sent: Monday, January 07, 2002 10:12 PM
To: sip@ietf.org
Subject: Re: [Sip] Default value for Timer C (was #282)


In the circuit switch world, the equivalent of "Timer C" exists.
On a 5ESS, ringback turns to fast busy after 3 minutes.  On a 4ESS,
it happens after 90 seconds.  (Both figures were as of a few years
ago, but I doubt they have changed).  Perhaps someone from Nortel
could speak of the DMS switches.  Also as of a few years ago,
business customers paid for ring time, so if still true, it is not
clear why AA is "cheating".

So a timeout value of a couple of minutes (like 4) would work
just fine for calls into the PSTN, and would only get hit for
a high-and-dry type of defect.

Bill Marshall
wtm@research.att.com

-----original message-----
From: John.Hearty@Level3.com
Subject: RE: [Sip] Default value for Timer C (was #282)
Date: Mon, 7 Jan 2002 15:56:14 -0700

 I agree with Bob.  AA is apparently cheating here, doing all their IVR
functions without returning answer.  I vote for the alternative, choosing a
value on the order of minutes (not more than maybey three or four).

John Hearty
Level3

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, January 07, 2002 3:33 PM
To: Bob Penfield
Cc: Henry Sinnreich; 'Robert Sparks'; sip@ietf.org
Subject: Re: [Sip] Default value for Timer C (was #282)


This thread has stalled, and I think it requires some further input
before we can resolve it.

The issue was this: what minimum timer do we mandate for a proxy to hang
onto invite transaction state after receiving 1xx? The issue is that
some PSTN systems (american airlines in particular), appear to use early
media while a user is on hold waiting, or using the DTMF based IVR
system. The result is that a call from a PC to a PSTN number could, in
theory go legitimately unanswered for hours, perhaps. This would require
that Timer C in proxies be on the order of hours, which is quite large.

An alternative is to not consider this case, and choose a smaller value,
on the order of minutes.

Both can result in DoS attacks, although in this case, the proxy
shouldn't be storing transaction state for unauthenticated requests.

Determining whether or not to go with a large value depends a lot on how
common such systems are in the PSTN, and what the expectation is for
them to be properly supported.

Further inputs?

-Jonathan R.

Bob Penfield wrote:

>>>I have not _ever_ been able to successfully
>>>use my SIP equipment to have a successful dialog with AA.
>>>
>
> The same problem occurs using old-world TDM equipment. If I use my
> calling
> card account to call AA, it hangs up after about a minute because the
> calling card platform has a 60 second answer timer. AA is trying to save
> money by having their ACD not return an answer and thus they don't have
> to
> pay for the 800 call.
>
> BTW, all billing is based on answer (2xx for SIP) being returned by the
> called party. Some systems (usually in hotels) do use a timer when
> answer
> cannot be determined reliably (or they don't care).
>
> I'm curious as to whether this was isolated to a proxy or is it possible
> the
> TDM side of the gateway is dropping the call? If gateways have answer
> timers
> on this order of magnitude, having a really long timer in the proxy
> won't
> help.
>
> In any event, do we really need to support these cheaters in SIP and
> open
> ourselves to DOS attacks?
>
>
>>I have exactly the same experience.
>>As for:
>>
>>
>>>Now, if all the SIP parties involved allowed me to 1) control my
>>>own Expires header, and 2) actually honored the thing,
>>>
>>I don't know how to tweak to and I don't ever want to know.
>>
>>Is there a better approach to fix the timer value or am I missing
>>something?
>>
>>Thanks, Henry
>>
>>
>>>-----Original Message-----
>>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of
>>>
>>Robert
>>
>>>Sparks
>>>Sent: Thursday, December 27, 2001 9:57 AM
>>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks
>>>Cc: sip@ietf.org
>>>Subject: [Sip] Default value for Timer C (was #282)
>>>
>>>I'm talking about a _real problem_ that I have
>>>_right now_ with the UAs on my desk and the gateways
>>>I have access to. I have not _ever_ been able to successfully
>>>use my SIP equipment to have a successful dialog with AA.
>>>Try it - call +18004337300 - my environment drops the unanswered
>>>call about 58 seconds into the first menu (yes, the first menu
>>>is over a minute long).
>>>
>>>Now, if all the SIP parties involved allowed me to 1) control my
>>>own Expires header, and 2) actually honored the thing, I could
>>>work around it. But what about my tweak-phobic aquaintances
>>>and relatives?
>>>
>>>In this case, the endpoints are dropping the call, but if I had
>>>otherwise behaving endpoints, and a proxy in the middle with a
>>>_default_ Timer C value that is too small, I am left with
>>>at least one well-known service that just doesn't work.
>>>
>>>Now, we could get into a discussion about whether or not a service
>>>_should_ run a whole bunch of time in an early media state, but
>>>that's rather moot - we've worked really hard to make the system
>>>allow it, and it will be used. We're here on purpose, not by
>>>misfortune of oversight.
>>>
>>>As for your last paragraph - who says early media has to be free?
>>>
>>>RjS
>>>
>>>
>>>
>>>>From: Bob Penfield [mailto:bpenfield@acmepacket.com]
>>>>
>>>>>>If this is acceptable, it still leaves us with the question
>>>>>>of what value we should recommend. I propose something
>>>>>>long - order of .5 to 1 hour (remember that calls stay in a
>>>>>>provisional state with early media when you are in the queue
>>>>>>to talk to an AA representative).
>>>>>>
>>>>>
>>>>>Egads, thats a long time! Your point on early media is well
>>>>>
> taken,
>
>>>>>though. Arguably, if this case happens, 1 hour is not even
>>>>>
>>>>enough, since
>>>>
>>>>>I have certainly been on hold for durations longer than
>>>>>
>>>>that. Probably 4
>>>>
>>>>>hours is more reasonable. Once you've set the timer this
>>>>>
>>>>high, it may as
>>>>
>>>>>well be any finite number as far as the proxy is concerned. The
>>>>>
>>only
>>
>>>>>value in having a number at all (as opposed to infinity) is
>>>>>
>>>>very long
>>>>
>>>>>term garbage collection. You will get NO DoS attack prevention
>>>>>
>>from
>>
>>>>>numbers of this magnitude. You really need to be careful,
>>>>>
>>>>as a proxy, to
>>>>
>>>>>not create transaction state unless the request is
>>>>>
>>>>authenticated somehow.
>>>>
>>>>I don't think this really applies. I believe that most ACD
>>>>systems that put
>>>>you on hold actually do answer the call. Especially ones that
>>>>have DTMF
>>>>menus since some carriers block the caller to callee
>>>>connection until it is
>>>>answered. Many TDM switches that I have experience with will
>>>>tear down an
>>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3
>>>>minute timer
>>>>would be adequate.
>>>>
>>>>But, this is not the TDM world. So, if we want to provide for
>>>>unanswered
>>>>calls being queued for long periods of time, maybe we could
>>>>require the UAS
>>>>to send periodic provisional responses and the proxy could
>>>>reset Timer C.
>>>>But that may be getting to complicated.
>>>>
>>>>Service providers who charge for these calls don't want their
>>>>resources used
>>>>for free for such a long period of time.
>>>>
>>>>cheers,
>>>>(-:bob
>>>>
>>>>
>>>>_______________________________________________
>>>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>>>This list is for NEW development of the core SIP Protocol
>>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>>Use sipping@ietf.org for new developments on the application of
>>>>
> sip
>
>>>_______________________________________________
>>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol
>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>Use sipping@ietf.org for new developments on the application of sip
>>>
>>
>


--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


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

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

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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_01C1985A.62E296A0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 11:26:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28347 for ; Tue, 8 Jan 2002 11:26:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06504 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 11:26:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06025; Tue, 8 Jan 2002 11:09:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05996 for ; Tue, 8 Jan 2002 11:09:35 -0500 (EST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27415 for ; Tue, 8 Jan 2002 11:09:33 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA17595 for ; Tue, 8 Jan 2002 09:09:35 -0700 (MST)] Received: [from az33exi01.corp.mot.com (az33exi01.corp.mot.com [199.2.84.10]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA25735 for ; Tue, 8 Jan 2002 09:09:35 -0700 (MST)] Received: by az33exi01.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 8 Jan 2002 09:09:34 -0700 Message-ID: From: Purcell Michael-QA3001 To: "'sip@ietf.org'" Cc: Purcell Michael-QA3001 Date: Tue, 8 Jan 2002 09:09:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] rfc2543bis.05 Content-Disposition. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In rfc2543bis.05 for the field, Content-Disposition field Is it legal to execute "Re-INVITEs" with content-Disposition set to "icon", then "alert", then "session"? Thanks Mike Purcell _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 11:29:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28447 for ; Tue, 8 Jan 2002 11:29:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06549 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 11:29:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05676; Tue, 8 Jan 2002 11:02:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05648 for ; Tue, 8 Jan 2002 11:02:47 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26987 for ; Tue, 8 Jan 2002 11:02:45 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA19978 for ; Tue, 8 Jan 2002 09:02:46 -0700 (MST)] Received: [from az33exi01.corp.mot.com (az33exi01.corp.mot.com [199.2.84.10]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA02505 for ; Tue, 8 Jan 2002 09:02:46 -0700 (MST)] Received: by az33exi01.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 8 Jan 2002 09:02:45 -0700 Message-ID: From: Purcell Michael-QA3001 To: "'sip@ietf.org'" Cc: Purcell Michael-QA3001 Date: Tue, 8 Jan 2002 09:02:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] draft-ietf-sip-rfc2543bis-05 format Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In this document in section 22 there are several references to H-something.something, for example on page 132 there is an [H3.5]. What is this reference pointing to, I cannot find anything. Thanks Mike Purcell _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 11:38:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28819 for ; Tue, 8 Jan 2002 11:38:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07089 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 11:38:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06377; Tue, 8 Jan 2002 11:19:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06346 for ; Tue, 8 Jan 2002 11:19:20 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27914 for ; Tue, 8 Jan 2002 11:19:18 -0500 (EST) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g08GJKR33765; Tue, 8 Jan 2002 11:19:20 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] draft-ietf-sip-rfc2543bis-05 format Date: Tue, 8 Jan 2002 11:21:32 -0500 Message-ID: <002b01c19860$89928d90$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit It refers to RFC 2616. The abbreviation is defined in section 7. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Purcell > Michael-QA3001 > Sent: Tuesday, January 08, 2002 11:03 AM > To: 'sip@ietf.org' > Cc: Purcell Michael-QA3001 > Subject: [Sip] draft-ietf-sip-rfc2543bis-05 format > > > In this document in section 22 there are several references > to H-something.something, for example on page 132 there is an [H3.5]. > What is this reference pointing to, I cannot find anything. > > Thanks Mike Purcell > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 12:03:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29975 for ; Tue, 8 Jan 2002 12:03:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09359 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 12:03:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07223; Tue, 8 Jan 2002 11:40:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07116 for ; Tue, 8 Jan 2002 11:40:22 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28882 for ; Tue, 8 Jan 2002 11:40:19 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g08GW5vw010003; Tue, 8 Jan 2002 11:32:06 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Jan 2002 11:33:51 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E926@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'John.Hearty@Level3.com'" , taylor@nortelnetworks.com, wtm@research.att.com, sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 11:33:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19862.40F26DC7" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19862.40F26DC7 Content-Type: text/plain; charset="iso-8859-1" 3 minutes seems a reasonable compromise. That will allow all but one of the ringtime applications I am aware of work. I will begrudgingly accept it. What this means is that any application that has a ringtime component can only count on the overall system providing a maximum of 3 minutes of ringtime (since some proxy in the path may have chosen to set Timer C to its 3 minute minimum). It also means that until we do some other kind of work, we preclude access to american airlines telephone service from the SIP world. (I _have_ stayed in the queue on their system for significantly longer than 5 minutes from multiple residential, wireless, and PBX phones, so something besides the timers discussed below is in play). So, since the consensus is that really long timer C's are not the way to address this problem, what's the alternative? Pretending the problem doesn't exist is unacceptable. RjS -----Original Message----- From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] Sent: Tuesday, January 08, 2002 9:38 AM To: taylor@nortelnetworks.com; wtm@research.att.com; sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) When I worked on the DMS several years ago, the timer was configurable, the company set it for 2 minutes. I'm hearing a general concensus the timer should be in the 1-5 minute range. Perhaps 3 minutes would be agreeable to most. Haven't heard anyone new pipe up for very long times... John Hearty Level3 -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Tuesday, January 08, 2002 8:10 AM To: 'William Marshall'; sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) A long time since I looked at that code, but I seem to recall a timeout after three minutes of ringing on the DMS. -----Original Message----- From: William Marshall [ mailto:wtm@research.att.com ] Sent: Monday, January 07, 2002 10:12 PM To: sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) In the circuit switch world, the equivalent of "Timer C" exists. On a 5ESS, ringback turns to fast busy after 3 minutes. On a 4ESS, it happens after 90 seconds. (Both figures were as of a few years ago, but I doubt they have changed). Perhaps someone from Nortel could speak of the DMS switches. Also as of a few years ago, business customers paid for ring time, so if still true, it is not clear why AA is "cheating". So a timeout value of a couple of minutes (like 4) would work just fine for calls into the PSTN, and would only get hit for a high-and-dry type of defect. Bill Marshall wtm@research.att.com -----original message----- From: John.Hearty@Level3.com Subject: RE: [Sip] Default value for Timer C (was #282) Date: Mon, 7 Jan 2002 15:56:14 -0700 I agree with Bob. AA is apparently cheating here, doing all their IVR functions without returning answer. I vote for the alternative, choosing a value on the order of minutes (not more than maybey three or four). John Hearty Level3 -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Monday, January 07, 2002 3:33 PM To: Bob Penfield Cc: Henry Sinnreich; 'Robert Sparks'; sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) This thread has stalled, and I think it requires some further input before we can resolve it. The issue was this: what minimum timer do we mandate for a proxy to hang onto invite transaction state after receiving 1xx? The issue is that some PSTN systems (american airlines in particular), appear to use early media while a user is on hold waiting, or using the DTMF based IVR system. The result is that a call from a PC to a PSTN number could, in theory go legitimately unanswered for hours, perhaps. This would require that Timer C in proxies be on the order of hours, which is quite large. An alternative is to not consider this case, and choose a smaller value, on the order of minutes. Both can result in DoS attacks, although in this case, the proxy shouldn't be storing transaction state for unauthenticated requests. Determining whether or not to go with a large value depends a lot on how common such systems are in the PSTN, and what the expectation is for them to be properly supported. Further inputs? -Jonathan R. Bob Penfield wrote: >>>I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>> > > The same problem occurs using old-world TDM equipment. If I use my > calling > card account to call AA, it hangs up after about a minute because the > calling card platform has a 60 second answer timer. AA is trying to save > money by having their ACD not return an answer and thus they don't have > to > pay for the 800 call. > > BTW, all billing is based on answer (2xx for SIP) being returned by the > called party. Some systems (usually in hotels) do use a timer when > answer > cannot be determined reliably (or they don't care). > > I'm curious as to whether this was isolated to a proxy or is it possible > the > TDM side of the gateway is dropping the call? If gateways have answer > timers > on this order of magnitude, having a really long timer in the proxy > won't > help. > > In any event, do we really need to support these cheaters in SIP and > open > ourselves to DOS attacks? > > >>I have exactly the same experience. >>As for: >> >> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, >>> >>I don't know how to tweak to and I don't ever want to know. >> >>Is there a better approach to fix the timer value or am I missing >>something? >> >>Thanks, Henry >> >> >>>-----Original Message----- >>>From: sip-admin@ietf.org [ mailto:sip-admin@ietf.org ] On Behalf Of >>> >>Robert >> >>>Sparks >>>Sent: Thursday, December 27, 2001 9:57 AM >>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks >>>Cc: sip@ietf.org >>>Subject: [Sip] Default value for Timer C (was #282) >>> >>>I'm talking about a _real problem_ that I have >>>_right now_ with the UAs on my desk and the gateways >>>I have access to. I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>>Try it - call +18004337300 - my environment drops the unanswered >>>call about 58 seconds into the first menu (yes, the first menu >>>is over a minute long). >>> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, I could >>>work around it. But what about my tweak-phobic aquaintances >>>and relatives? >>> >>>In this case, the endpoints are dropping the call, but if I had >>>otherwise behaving endpoints, and a proxy in the middle with a >>>_default_ Timer C value that is too small, I am left with >>>at least one well-known service that just doesn't work. >>> >>>Now, we could get into a discussion about whether or not a service >>>_should_ run a whole bunch of time in an early media state, but >>>that's rather moot - we've worked really hard to make the system >>>allow it, and it will be used. We're here on purpose, not by >>>misfortune of oversight. >>> >>>As for your last paragraph - who says early media has to be free? >>> >>>RjS >>> >>> >>> >>>>From: Bob Penfield [ mailto:bpenfield@acmepacket.com ] >>>> >>>>>>If this is acceptable, it still leaves us with the question >>>>>>of what value we should recommend. I propose something >>>>>>long - order of .5 to 1 hour (remember that calls stay in a >>>>>>provisional state with early media when you are in the queue >>>>>>to talk to an AA representative). >>>>>> >>>>> >>>>>Egads, thats a long time! Your point on early media is well >>>>> > taken, > >>>>>though. Arguably, if this case happens, 1 hour is not even >>>>> >>>>enough, since >>>> >>>>>I have certainly been on hold for durations longer than >>>>> >>>>that. Probably 4 >>>> >>>>>hours is more reasonable. Once you've set the timer this >>>>> >>>>high, it may as >>>> >>>>>well be any finite number as far as the proxy is concerned. The >>>>> >>only >> >>>>>value in having a number at all (as opposed to infinity) is >>>>> >>>>very long >>>> >>>>>term garbage collection. You will get NO DoS attack prevention >>>>> >>from >> >>>>>numbers of this magnitude. You really need to be careful, >>>>> >>>>as a proxy, to >>>> >>>>>not create transaction state unless the request is >>>>> >>>>authenticated somehow. >>>> >>>>I don't think this really applies. I believe that most ACD >>>>systems that put >>>>you on hold actually do answer the call. Especially ones that >>>>have DTMF >>>>menus since some carriers block the caller to callee >>>>connection until it is >>>>answered. Many TDM switches that I have experience with will >>>>tear down an >>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3 >>>>minute timer >>>>would be adequate. >>>> >>>>But, this is not the TDM world. So, if we want to provide for >>>>unanswered >>>>calls being queued for long periods of time, maybe we could >>>>require the UAS >>>>to send periodic provisional responses and the proxy could >>>>reset Timer C. >>>>But that may be getting to complicated. >>>> >>>>Service providers who charge for these calls don't want their >>>>resources used >>>>for free for such a long period of time. >>>> >>>>cheers, >>>>(-:bob >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of >>>> > sip > >>>_______________________________________________ >>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C19862.40F26DC7 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Default value for Timer C (was #282)
3 minutes seems a reasonable compromise. That will allow all but one of the ringtime
applications I am aware of work. I will begrudgingly accept it.
 
What this means is that any application that has a ringtime component can only
count on the overall system providing a maximum of 3 minutes of ringtime (since
some proxy in the path may have chosen to set Timer C to its 3 minute minimum).
 
It also means that until we do some other kind of work, we preclude access to
american airlines telephone service from the SIP world. (I _have_ stayed in the queue
on their system for significantly longer than 5 minutes from multiple residential, wireless,
and PBX phones, so something besides the timers discussed below is in play).
So, since the consensus is that really long timer C's are not the way to address this
problem, what's the alternative? Pretending the problem doesn't exist is unacceptable.
 
RjS
 
-----Original Message-----
From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com]
Sent: Tuesday, January 08, 2002 9:38 AM
To: taylor@nortelnetworks.com; wtm@research.att.com; sip@ietf.org
Subject: RE: [Sip] Default value for Timer C (was #282)

When I worked on the DMS several years ago, the timer was configurable, the company set it for 2 minutes.  I'm hearing a general concensus the timer should be in the 1-5 minute range.  Perhaps 3 minutes would be agreeable to most.  Haven't heard anyone new pipe up for very long times...
 
John Hearty
Level3
 
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, January 08, 2002 8:10 AM
To: 'William Marshall'; sip@ietf.org
Subject: RE: [Sip] Default value for Timer C (was #282)

A long time since I looked at that code, but I seem to recall a timeout after three minutes of ringing on the DMS.

-----Original Message-----
From: William Marshall [mailto:wtm@research.att.com]
Sent: Monday, January 07, 2002 10:12 PM
To: sip@ietf.org
Subject: Re: [Sip] Default value for Timer C (was #282)


In the circuit switch world, the equivalent of "Timer C" exists.
On a 5ESS, ringback turns to fast busy after 3 minutes.  On a 4ESS,
it happens after 90 seconds.  (Both figures were as of a few years
ago, but I doubt they have changed).  Perhaps someone from Nortel
could speak of the DMS switches.  Also as of a few years ago,
business customers paid for ring time, so if still true, it is not
clear why AA is "cheating".

So a timeout value of a couple of minutes (like 4) would work
just fine for calls into the PSTN, and would only get hit for
a high-and-dry type of defect.

Bill Marshall
wtm@research.att.com

-----original message-----
From: John.Hearty@Level3.com
Subject: RE: [Sip] Default value for Timer C (was #282)
Date: Mon, 7 Jan 2002 15:56:14 -0700

 I agree with Bob.  AA is apparently cheating here, doing all their IVR
functions without returning answer.  I vote for the alternative, choosing a
value on the order of minutes (not more than maybey three or four).

John Hearty
Level3

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, January 07, 2002 3:33 PM
To: Bob Penfield
Cc: Henry Sinnreich; 'Robert Sparks'; sip@ietf.org
Subject: Re: [Sip] Default value for Timer C (was #282)


This thread has stalled, and I think it requires some further input
before we can resolve it.

The issue was this: what minimum timer do we mandate for a proxy to hang
onto invite transaction state after receiving 1xx? The issue is that
some PSTN systems (american airlines in particular), appear to use early
media while a user is on hold waiting, or using the DTMF based IVR
system. The result is that a call from a PC to a PSTN number could, in
theory go legitimately unanswered for hours, perhaps. This would require
that Timer C in proxies be on the order of hours, which is quite large.

An alternative is to not consider this case, and choose a smaller value,
on the order of minutes.

Both can result in DoS attacks, although in this case, the proxy
shouldn't be storing transaction state for unauthenticated requests.

Determining whether or not to go with a large value depends a lot on how
common such systems are in the PSTN, and what the expectation is for
them to be properly supported.

Further inputs?

-Jonathan R.

Bob Penfield wrote:

>>>I have not _ever_ been able to successfully
>>>use my SIP equipment to have a successful dialog with AA.
>>>
>
> The same problem occurs using old-world TDM equipment. If I use my
> calling
> card account to call AA, it hangs up after about a minute because the
> calling card platform has a 60 second answer timer. AA is trying to save
> money by having their ACD not return an answer and thus they don't have
> to
> pay for the 800 call.
>
> BTW, all billing is based on answer (2xx for SIP) being returned by the
> called party. Some systems (usually in hotels) do use a timer when
> answer
> cannot be determined reliably (or they don't care).
>
> I'm curious as to whether this was isolated to a proxy or is it possible
> the
> TDM side of the gateway is dropping the call? If gateways have answer
> timers
> on this order of magnitude, having a really long timer in the proxy
> won't
> help.
>
> In any event, do we really need to support these cheaters in SIP and
> open
> ourselves to DOS attacks?
>
>
>>I have exactly the same experience.
>>As for:
>>
>>
>>>Now, if all the SIP parties involved allowed me to 1) control my
>>>own Expires header, and 2) actually honored the thing,
>>>
>>I don't know how to tweak to and I don't ever want to know.
>>
>>Is there a better approach to fix the timer value or am I missing
>>something?
>>
>>Thanks, Henry
>>
>>
>>>-----Original Message-----
>>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of
>>>
>>Robert
>>
>>>Sparks
>>>Sent: Thursday, December 27, 2001 9:57 AM
>>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks
>>>Cc: sip@ietf.org
>>>Subject: [Sip] Default value for Timer C (was #282)
>>>
>>>I'm talking about a _real problem_ that I have
>>>_right now_ with the UAs on my desk and the gateways
>>>I have access to. I have not _ever_ been able to successfully
>>>use my SIP equipment to have a successful dialog with AA.
>>>Try it - call +18004337300 - my environment drops the unanswered
>>>call about 58 seconds into the first menu (yes, the first menu
>>>is over a minute long).
>>>
>>>Now, if all the SIP parties involved allowed me to 1) control my
>>>own Expires header, and 2) actually honored the thing, I could
>>>work around it. But what about my tweak-phobic aquaintances
>>>and relatives?
>>>
>>>In this case, the endpoints are dropping the call, but if I had
>>>otherwise behaving endpoints, and a proxy in the middle with a
>>>_default_ Timer C value that is too small, I am left with
>>>at least one well-known service that just doesn't work.
>>>
>>>Now, we could get into a discussion about whether or not a service
>>>_should_ run a whole bunch of time in an early media state, but
>>>that's rather moot - we've worked really hard to make the system
>>>allow it, and it will be used. We're here on purpose, not by
>>>misfortune of oversight.
>>>
>>>As for your last paragraph - who says early media has to be free?
>>>
>>>RjS
>>>
>>>
>>>
>>>>From: Bob Penfield [mailto:bpenfield@acmepacket.com]
>>>>
>>>>>>If this is acceptable, it still leaves us with the question
>>>>>>of what value we should recommend. I propose something
>>>>>>long - order of .5 to 1 hour (remember that calls stay in a
>>>>>>provisional state with early media when you are in the queue
>>>>>>to talk to an AA representative).
>>>>>>
>>>>>
>>>>>Egads, thats a long time! Your point on early media is well
>>>>>
> taken,
>
>>>>>though. Arguably, if this case happens, 1 hour is not even
>>>>>
>>>>enough, since
>>>>
>>>>>I have certainly been on hold for durations longer than
>>>>>
>>>>that. Probably 4
>>>>
>>>>>hours is more reasonable. Once you've set the timer this
>>>>>
>>>>high, it may as
>>>>
>>>>>well be any finite number as far as the proxy is concerned. The
>>>>>
>>only
>>
>>>>>value in having a number at all (as opposed to infinity) is
>>>>>
>>>>very long
>>>>
>>>>>term garbage collection. You will get NO DoS attack prevention
>>>>>
>>from
>>
>>>>>numbers of this magnitude. You really need to be careful,
>>>>>
>>>>as a proxy, to
>>>>
>>>>>not create transaction state unless the request is
>>>>>
>>>>authenticated somehow.
>>>>
>>>>I don't think this really applies. I believe that most ACD
>>>>systems that put
>>>>you on hold actually do answer the call. Especially ones that
>>>>have DTMF
>>>>menus since some carriers block the caller to callee
>>>>connection until it is
>>>>answered. Many TDM switches that I have experience with will
>>>>tear down an
>>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3
>>>>minute timer
>>>>would be adequate.
>>>>
>>>>But, this is not the TDM world. So, if we want to provide for
>>>>unanswered
>>>>calls being queued for long periods of time, maybe we could
>>>>require the UAS
>>>>to send periodic provisional responses and the proxy could
>>>>reset Timer C.
>>>>But that may be getting to complicated.
>>>>
>>>>Service providers who charge for these calls don't want their
>>>>resources used
>>>>for free for such a long period of time.
>>>>
>>>>cheers,
>>>>(-:bob
>>>>
>>>>
>>>>_______________________________________________
>>>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>>>This list is for NEW development of the core SIP Protocol
>>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>>Use sipping@ietf.org for new developments on the application of
>>>>
> sip
>
>>>_______________________________________________
>>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol
>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>Use sipping@ietf.org for new developments on the application of sip
>>>
>>
>


--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


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

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

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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_01C19862.40F26DC7-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 12:33:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01311 for ; Tue, 8 Jan 2002 12:33:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11257 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 12:33:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10027; Tue, 8 Jan 2002 12:16:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09996 for ; Tue, 8 Jan 2002 12:16:05 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00600 for ; Tue, 8 Jan 2002 12:16:02 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08H07VZ009417; Tue, 8 Jan 2002 12:00:07 -0500 (EST) Message-ID: <3C3B2577.7070002@dynamicsoft.com> Date: Tue, 08 Jan 2002 11:59:35 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Sparks CC: "'John.Hearty@Level3.com'" , taylor@nortelnetworks.com, wtm@research.att.com, sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) References: <9BF66EBF6BEFD942915B4D4D45C051F338E926@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert Sparks wrote: > It also means that until we do some other kind of work, we preclude > access to > american airlines telephone service from the SIP world. (I _have_ stayed > in the queue > on their system for significantly longer than 5 minutes from multiple > residential, wireless, > and PBX phones, so something besides the timers discussed below is in > play). > So, since the consensus is that really long timer C's are not the way to > address this > problem, what's the alternative? Pretending the problem doesn't exist is > unacceptable. Actually, its not clear to me that things won't work with timer C at 3m. Lets say you've called AA, and after 3m, the proxies give up. Let us say that the DONT CANCEL, but just discard all state. The terminating GW doesnt' give up, since it knows there is media in progress. Same with your calling UAC. Now, after 30m, the call is answered. A 200 OK is sent by the terminating GW. This 200 OK will be properly routed back to the UAC even without transaction state in any proxies. The ACK will be routed based on the route set, and should get there as well. If the call is rejected, a 4xx will be sent by the terminating GW. The previous hop proxy will statelessly forward it as well, and the behavior will effectively look like the 2xx/ACK case, with the 4xx being retransmitted by UAS, and the ACK by the UAC. The ACK for the non-2xx case won't have route headers, so it may or may not get delivered to the terminating gateway, but the odds are actually good. This is a fine example of the benefits of stateless operation. Things will break in the case of a forking proxy. If timer C expires and it doesn't cancel, the UAC may end up getting multiple non-2xx responses. There are a few possible solutions to this one: a. the proxy cancels all but one branch (the one that returned the 1xx), and then drops its state. This allows that one branch to continue b. so what if the uac gets multiple non-2xx. It accepts the first, drops the rest. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 12:35:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01434 for ; Tue, 8 Jan 2002 12:35:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11397 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 12:35:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10080; Tue, 8 Jan 2002 12:17:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10048 for ; Tue, 8 Jan 2002 12:17:04 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00628 for ; Tue, 8 Jan 2002 12:17:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08HH3VZ009436; Tue, 8 Jan 2002 12:17:03 -0500 (EST) Message-ID: <3C3B296F.4010401@dynamicsoft.com> Date: Tue, 08 Jan 2002 12:16:31 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: sip@ietf.org Subject: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > Section 8.1.1.7 of the bis draft (lines 948 through 952) appears to be the > text that allows pre-existing Route headers to be used in the initial > transaction of a dialogue, or in a stand-alone transaction. > > "8.1.1.7 Request-URI The initial Request-URI of the message SHOULD > be set to the value of the URI in the To field. One notable exception is the > REGISTER method; behavior for setting the Request-URI of register is given > in Section 10. Another exception is the case of pre-existing Route headers; > in that case, the procedures of Section 12.2.1.1 as they pertain to the > Request- URI are followed, even though there is no dialog." Right. We'll add a bit more text to explain what a "pre-existing route" is. > > A set of Route headers created using the Record-Route mechanism carries the > mechanism to ensure that when the route traverses a spiral, all the URLs in > the Record-Route headers are unique, and therefore that the set of Route > headers is also unique. Actually, I am not sure thats really needed anymore for routed requests. Here's why. Remember, the point of loop detection is to reject a request when you know that its processing will cause you do to the same thing to it you did last time. Proxy processing is not based just on the URI; in the case of Route headers, the overall processing is the same only if the Route set through the loop has not changed. One of the things we have now in bis is that a proxy computes, as part of the via branch ID, a hash of those things in the request that affect its processing. Effectively, if this includes a hash of the route set, there is no need to ensure that the URI in the route set are not identical. Realistically I expect they almost always would be anyway, though. I am beginning to wonder, however, whether or not this whole business of loop detection is worth the trouble. The Max-Forwards mechanism provides a sufficient way to ensure that they don't persist forever. The loop detection mecahnism is more efficient, but given the probability of occurence in a well-engineered network, I'm not sure its worth all the pain it causes, and it does cause pain. A proxy has to hash over a bunch of headers that it otherwise might be able to ignore... Anyone for deprecating loop detection? A proxy that doesn't do it would have to insert max-forwards if not already present, that is the penalty. We also need a minimum value for Max-Forwards, something like 20 is more than sufficient, I think. This is has the nice side effect of making the branch ID just a pure transaction identifier, as it should be. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 12:36:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01488 for ; Tue, 8 Jan 2002 12:36:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11461 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 12:36:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10177; Tue, 8 Jan 2002 12:19:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10148 for ; Tue, 8 Jan 2002 12:19:21 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00781 for ; Tue, 8 Jan 2002 12:19:19 -0500 (EST) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g08HJL849885; Tue, 8 Jan 2002 12:19:21 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 12:21:33 -0500 Message-ID: <002e01c19868$ec3595c0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E926@DYN-TX-EXCH-001.dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > It also means that until we do some > other kind of work, we preclude access > to american airlines telephone service > from the SIP world. (I _have_ stayed in > the queue on their system for > significantly longer than 5 minutes from > multiple residential, wireless, and PBX > phones, so something besides the timers > discussed below is in play). So, since > the consensus is that really long timer > C's are not the way to address this > problem, what's the alternative? It is the gateway's decision. It can send a 200 prior to expiration or a 408 upon expiration. Such a choice would be based upon associated billing and resource usage policies and regulations. And added option could be for the UAC or it's proxy to include something to indicate its willingness to accept billing charges associated with long call setup times. However since SIP doesn't deal with billing, I guess SIPPING can identify a mechanism or need to communicate such a thing. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 12:36:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01504 for ; Tue, 8 Jan 2002 12:36:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11475 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 12:36:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10371; Tue, 8 Jan 2002 12:22:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10340 for ; Tue, 8 Jan 2002 12:22:42 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00926 for ; Tue, 8 Jan 2002 12:22:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08HM4VZ009443; Tue, 8 Jan 2002 12:22:06 -0500 (EST) Message-ID: <3C3B2A9D.4090209@dynamicsoft.com> Date: Tue, 08 Jan 2002 12:21:33 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: John.Hearty@Level3.com, sip@ietf.org, Jean Mahoney Subject: Re: [Sip] bis-05 mostly NITS - full review Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > >>>69. Line 3299, what about TLS transport (port 5061)? >>> >>Yeah, this is a big mess with that. One of the reasons I sent a query asking >>about whether people put 5060 into the URL even though its the default, was >>to try and change this behavior to have sip:user@host:5060 NOT equal >>sip:user@host, since the former would use SRV and the latter wouldn't. >>Unfortunately, it seems at least a few people are putting 5060 in the >>URLs.... >> > > We should also remember tat the host may be an IP address, and the > client does not use SRV. So, if there is no port, and it does NOT mean > that 5060 shall be used as default, which port does the client use? This is discussed in the new draft-ietf-sip-srv-03. It uses the default port for the transport. If there is no transport, its the default transport (UDP). > > And, to say that 5060 is default if the host is an IP address, but not > if the host is a domain name, may sound a little messy? Based on the rules in draft-ietf-sip-srv, if the host is a domain name vs. an ip address for the same transport, the default port is the same, unless the domain resolves with SRV and it specifies an alternate. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 12:54:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02394 for ; Tue, 8 Jan 2002 12:54:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12341 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 12:54:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11739; Tue, 8 Jan 2002 12:41:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11691 for ; Tue, 8 Jan 2002 12:41:41 -0500 (EST) Received: from zeus.anet-chi.com (root@zeus.anet-chi.com [207.7.4.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01740 for ; Tue, 8 Jan 2002 12:41:40 -0500 (EST) Received: from RepliGate (as1b-39.chi.il.dial.anet.com [198.92.157.39]) by zeus.anet-chi.com (8.12.1/8.12.0) with SMTP id g08Hfbop027871; Tue, 8 Jan 2002 11:41:38 -0600 (CST) Message-ID: <1b7d01c19884$62385ad0$0100a8c0@RepliGate> From: "Jim Fleming" To: "Jonathan Rosenberg" , "Christer Holmberg" Cc: , , "Jean Mahoney" References: <3C3B2A9D.4090209@dynamicsoft.com> Subject: Re: [Sip] bis-05 mostly NITS - full review Date: Tue, 8 Jan 2002 12:38: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 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jonathan Rosenberg" To: "Christer Holmberg" > > > > We should also remember tat the host may be an IP address, and the > > client does not use SRV. So, if there is no port, and it does NOT mean > > that 5060 shall be used as default, which port does the client use? > > > This is discussed in the new draft-ietf-sip-srv-03. It uses the default > port for the transport. If there is no transport, its the default > transport (UDP). > UDP uses Ports.... Do you use a 2002 prefix ? http://www.dot-biz.com/INFO/Papers/ Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 12:54:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02423 for ; Tue, 8 Jan 2002 12:54:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12357 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 12:54:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11804; Tue, 8 Jan 2002 12:41:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11761 for ; Tue, 8 Jan 2002 12:41:50 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01749 for ; Tue, 8 Jan 2002 12:41:49 -0500 (EST) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g08HJhW22164; Tue, 8 Jan 2002 11:19:44 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g08HJhN06951; Tue, 8 Jan 2002 11:19:43 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA20554; Tue, 8 Jan 2002 11:19:43 -0600 (CST) Reply-To: To: "'Robert Sparks'" , , , , Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 11:19:40 -0600 Message-ID: <61D824C63B99D311975E00508B0CC98502C66D4B@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E926@DYN-TX-EXCH-001.dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I know I'm entering this thread late (I'm a bit behind on the list), but I just *need* to object. In particular, if we accept Robert's concession, this consensus makes the 182 status code almost completely worthless. This *isn't* a TDM architecture, and treating it as such is ridiculous. I was under the impression that everyone here understood that billing based on SIP signaling is a rather ridiculous proposition; given that, it should be obvious that remaining in a pre-answer state isn't any sort of an attempt to "cheat." It's obviously someone using the basic building blocks of SIP in a way that you may not have conceived in order to provide some service -- and I thought that's what the protocol was all about. Staying in a pre-answer state has several legitimate uses. Sending of 182 messages is one of the most obvious ("SIP/2.0 182 Call is queued; approximate wait is 13 minutes"), since it is endorsed by the specification itself. Robert has pointed out another real-world application (which happens to involve legacy systems). So, there's the theoretical problem to satisfy the purists, and the actual "someone you know has personally been inconvenienced by this" problem to satisfy those swayed by anecdotes: an arbitrary short limit on pre-answer states creates a real problem. There have already been proposals about how to work around this (e.g. re-sending provisional responses periodically), so I don't believe the impasse is technical in nature. That means we have a philosophical difference here. Everyone please inhale deeply, exhale slowly, and repeat to yourself: "This is not the PSTN. This is not the PSTN. This is not the PSTN." Then examine the problem from a SIP perspective. Keep the whole "generality" thing in mind, and consider whether you want to limit the number of services and the ways they can be implemented. /a _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 12:59:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02596 for ; Tue, 8 Jan 2002 12:59:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12517 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 12:59:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11755; Tue, 8 Jan 2002 12:41:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11693 for ; Tue, 8 Jan 2002 12:41:41 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01739 for ; Tue, 8 Jan 2002 12:41:40 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g08Heu018893; Tue, 8 Jan 2002 11:40:56 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 11:39:10 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E010AC7F3@zrc2c012.us.nortel.com> From: "Lathan Lewis" To: "'Jonathan Rosenberg'" , "Drage, Keith (Keith)" Cc: sip@ietf.org Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-exist ing Route headers Date: Tue, 8 Jan 2002 11:40:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1986B.827D31D0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1986B.827D31D0 Content-Type: text/plain; charset="iso-8859-1" I would agree with your proposal to deprecate loop detection based on the fact that it is becoming more complex and expensive to implement than it's worth. Our implementation currently relies on the Max-Forwards header as you propose and is using a default value of 20. Lathan Lewis Nortel Networks -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, January 08, 2002 11:17 AM To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Drage, Keith (Keith) wrote: > Section 8.1.1.7 of the bis draft (lines 948 through 952) appears to be the > text that allows pre-existing Route headers to be used in the initial > transaction of a dialogue, or in a stand-alone transaction. > > "8.1.1.7 Request-URI The initial Request-URI of the message SHOULD > be set to the value of the URI in the To field. One notable exception is the > REGISTER method; behavior for setting the Request-URI of register is given > in Section 10. Another exception is the case of pre-existing Route headers; > in that case, the procedures of Section 12.2.1.1 as they pertain to the > Request- URI are followed, even though there is no dialog." Right. We'll add a bit more text to explain what a "pre-existing route" is. > > A set of Route headers created using the Record-Route mechanism carries the > mechanism to ensure that when the route traverses a spiral, all the URLs in > the Record-Route headers are unique, and therefore that the set of Route > headers is also unique. Actually, I am not sure thats really needed anymore for routed requests. Here's why. Remember, the point of loop detection is to reject a request when you know that its processing will cause you do to the same thing to it you did last time. Proxy processing is not based just on the URI; in the case of Route headers, the overall processing is the same only if the Route set through the loop has not changed. One of the things we have now in bis is that a proxy computes, as part of the via branch ID, a hash of those things in the request that affect its processing. Effectively, if this includes a hash of the route set, there is no need to ensure that the URI in the route set are not identical. Realistically I expect they almost always would be anyway, though. I am beginning to wonder, however, whether or not this whole business of loop detection is worth the trouble. The Max-Forwards mechanism provides a sufficient way to ensure that they don't persist forever. The loop detection mecahnism is more efficient, but given the probability of occurence in a well-engineered network, I'm not sure its worth all the pain it causes, and it does cause pain. A proxy has to hash over a bunch of headers that it otherwise might be able to ignore... Anyone for deprecating loop detection? A proxy that doesn't do it would have to insert max-forwards if not already present, that is the penalty. We also need a minimum value for Max-Forwards, something like 20 is more than sufficient, I think. This is has the nice side effect of making the branch ID just a pure transaction identifier, as it should be. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C1986B.827D31D0 Content-Type: text/html; charset="iso-8859-1" RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers

I would agree with your proposal to deprecate loop detection based on
the fact that it is becoming more complex and expensive to implement than
it's worth. Our implementation currently relies on the Max-Forwards header
as you propose and is using a default value of 20.

Lathan Lewis
Nortel Networks

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, January 08, 2002 11:17 AM
To: Drage, Keith (Keith)
Cc: sip@ietf.org
Subject: Deprecate loop detection, was: Re: [Sip] bis draft:
Pre-existing Route headers




Drage, Keith (Keith) wrote:

> Section 8.1.1.7 of the bis draft (lines 948 through 952) appears to be the
> text that allows pre-existing Route headers to be used in the initial
> transaction of a dialogue, or in a stand-alone transaction.
>
>       "8.1.1.7 Request-URI The initial Request-URI of the message SHOULD
> be set to the value of the URI in the To field. One notable exception is the
> REGISTER method; behavior for setting the Request-URI of register is given
> in Section 10. Another exception is the case of pre-existing Route headers;
> in that case, the procedures of Section 12.2.1.1 as they pertain to the
> Request- URI are followed, even though there is no dialog."


Right. We'll add a bit more text to explain what a "pre-existing route" is.


>
> A set of Route headers created using the Record-Route mechanism carries the
> mechanism to ensure that when the route traverses a spiral, all the URLs in
> the Record-Route headers are unique, and therefore that the set of Route
> headers is also unique.


Actually, I am not sure thats really needed anymore for routed requests.
Here's why. Remember, the point of loop detection is to reject a request
when you know that its processing will cause you do to the same thing to
it you did last time. Proxy processing is not based just on the URI; in
the case of Route headers, the overall processing is the same only if
the Route set through the loop has not changed.

One of the things we have now in bis is that a proxy computes, as part
of the via branch ID, a hash of those things in the request that affect
its processing. Effectively, if this includes a hash of the route set,
there is no need to ensure that the URI in the route set are not
identical. Realistically I expect they almost always would be anyway,
though.

I am beginning to wonder, however, whether or not this whole business of
loop detection is worth the trouble. The Max-Forwards mechanism provides
a sufficient way to ensure that they don't persist forever. The loop
detection mecahnism is more efficient, but given the probability of
occurence in a well-engineered network, I'm not sure its worth all the
pain it causes, and it does cause pain. A proxy has to hash over a bunch
of headers that it otherwise might be able to ignore...

Anyone for deprecating loop detection? A proxy that doesn't do it would
have to insert max-forwards if not already present, that is the penalty.
  We also need a minimum value for Max-Forwards, something like 20 is
more than sufficient, I think.

This is has the nice side effect of making the branch ID just a pure
transaction identifier, as it should be.

Comments?

-Jonathan R.



--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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_01C1986B.827D31D0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 13:02:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02761 for ; Tue, 8 Jan 2002 13:02:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13051 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 13:02:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12123; Tue, 8 Jan 2002 12:48:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12020 for ; Tue, 8 Jan 2002 12:48:48 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02085 for ; Tue, 8 Jan 2002 12:48:47 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id RAA17173; Tue, 8 Jan 2002 17:45:59 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id RAA08548; Tue, 8 Jan 2002 17:48:40 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 10:48:35 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B37111@n0214idc1.oss.level3.com> To: jdrosen@dynamicsoft.com Cc: sip@ietf.org Subject: RE: [Sip] Open Issue #139: re-INVITE Glare Date: Tue, 8 Jan 2002 10:48:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Your points are all valid. I cannot think of a good alternative to be certain both sides agree there is glare. Since the probability of glare is not particularly high anyway, and in the interests of timely resolution of open issues, the latest timer solution seems acceptable. John Hearty Level3 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, January 01, 2002 9:42 PM > To: Hearty, John > Cc: orton@nortelnetworks.com; brett@broadsoft.com; sip@ietf.org > Subject: Re: [Sip] Open Issue #139: re-INVITE Glare > > > > > John.Hearty@Level3.com wrote: > > > > > >>I actually posted this to the list over a year back: > >> > >> I'm afraid this solution does not work as specified. It > only works > >> if both sides agree they are in a glare situation. Consider the > >> following case. A sends a reinvite to B. B receives it, > >>and responds > >> with a 200. This response takes a while to get to A. > Now, B sends a > >> re-INVITE to A (as far as B is concerned, the reinvite > it received > >> has been responded to, thus there is no glare, and it can > >>send a new > >> re-INVITE). A receives that re-invite. A thinks there is > glare, and > >> decides its the winner, so it responds. Then, A gets the non-500 > >> response from B. Now A is really confused. > >> > > > > This scenario would require packet re-ordering, with B's > 200 arriving at > > A > > after B's re-Invite. These are both going to the same > place, and these > > days, the likelyhood of packets between the same two places getting > > re-ordered is not that high. Granted, there are probabally proxies > > between > > increasing the likelyhood of the messages getting > re-ordered. However, > > do > > we really want to discard a cleaner solution for a small > percentage of > > negative scenarios? I have seen arguments in other threads against > > solving > > problems resulting when the network is totally hosed. > > > Its not reordering, so much as packet loss. All it takes is > one or two > lost 200 OK's, and the above scenario can happen without the network > doing any packet reordering. > > > > > > > >> You could argue that B shouldn't even send that > re-INVITE until the > >> ACK is received for the re-INVITE B got first. However, there is > >> still a race condition that makes it not work, although its even > >> less likely. Heres the case: A sends a re-invite to B that gets > >> lost. B sends a re-invite to A. A sees glare, and > decides A should > >> win, so it responds with a 200 OK. B ACKs, and A gets the > >>ACK. Then, that > >> lost reinvite arrives at B. B thinks everything is fine, > since the > >> previous reinvite it sent has been ACKed. So, it sends a 200 > >> OK. Now, A is once again confused. It expected B to reject > >>that first > >> INVITE, since A was declared the winner. > >> > > > > B better not think everything is fine, it just got an > Invite with the > > same > > Cseq it just used. > > > Same CSeq? These are in opposite directions. There is no relationship > between the CSeq in each direction. > > > Again, this scenario requires packet re-ordering > > between > > the same end points, not a highly likely thing to happen. > > > Packet loss is the problem, as I mentioned above. > > The proposed > > argument of not re-Inviting until after ACK seems to tie back to the > > overlapping Invite open issue #113, I am unclear where that left off > > other > > than it got ugly quickly and it seemed too late to resolve > in bis. This > > might be another reason to avoid overlapping Invites unless > it becomes a > > pressing need. I still feel we should avoid timers to > resolve glare if > > we > > can. They are inefficient. > > > I welcome alternatives, but I am pretty sure anything that relies on > both sides agreeing that there was glare is not going to work. > > > > > > > >> > >>Now, Brett had proposed a variant: > >> > >> > >>>However I agree with John that something > >>>should produce an early winner of the > >>>re-INVITE glare. How about allowing the > >>>owner of the Call-ID to have the random > >>>0 to 2 seconds (by 10ms) and the other > >>>gets random between 2.1 and 4 seconds > >>>(by 10ms)? Session refreshing induced > >>>reinvites should choose higher random > >>>backoff intervals assuming that there > >>>is time left to accommodate it. > >>> > >>> > >>There are cases where the "owner of the call-id" is also not known. > >>Consider the case where A calls B. A crashes. B detects > this through > >>ICMP on the media channel, and does a re-INVITE to re-establish. A > >>backup for A reconstitutes the state, and the call > continues. Now, A > >>thinks that B owns the Call-ID, and B thinks A owns it. Hmmm. > >> > > > > If A is smart enough to reconstitute state, it ought to be > smart enough > > to > > know if it owned the Call-ID. This could be a condition of > the proposal > > for > > issue #207. Otherwise, we don't have to stick with the > "owner of the > > Call-ID", there are other things unique to the transactions > that could > > be > > used to derive a definitive early winner. > > > Thats fair enough. This was definitely a minor point in > either case; I > thought Brett's proposal was reasonable, this issue aside. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 13:22:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03513 for ; Tue, 8 Jan 2002 13:22:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13815 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 13:22:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13151; Tue, 8 Jan 2002 13:04:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13119 for ; Tue, 8 Jan 2002 13:04:43 -0500 (EST) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02870 for ; Tue, 8 Jan 2002 13:04:41 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Tue, 8 Jan 2002 12:04:09 -0600 Message-ID: Thread-Topic: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Thread-Index: AcGYaT14elLgH85vQ+COf1QnsECnVQAArjQQ From: "Chiou, Mark" To: "Jonathan Rosenberg" , "Drage, Keith (Keith)" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA13121 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Please see comments inline. Thanks, Mark Chiou -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, January 08, 2002 11:17 AM To: Drage, Keith (Keith) Cc: sip@ietf.org Subject: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Drage, Keith (Keith) wrote: > Section 8.1.1.7 of the bis draft (lines 948 through 952) appears to be the > text that allows pre-existing Route headers to be used in the initial > transaction of a dialogue, or in a stand-alone transaction. > > "8.1.1.7 Request-URI The initial Request-URI of the message SHOULD > be set to the value of the URI in the To field. One notable exception is the > REGISTER method; behavior for setting the Request-URI of register is given > in Section 10. Another exception is the case of pre-existing Route headers; > in that case, the procedures of Section 12.2.1.1 as they pertain to the > Request- URI are followed, even though there is no dialog." Right. We'll add a bit more text to explain what a "pre-existing route" is. > > A set of Route headers created using the Record-Route mechanism carries the > mechanism to ensure that when the route traverses a spiral, all the URLs in > the Record-Route headers are unique, and therefore that the set of Route > headers is also unique. Actually, I am not sure thats really needed anymore for routed requests. Here's why. Remember, the point of loop detection is to reject a request when you know that its processing will cause you do to the same thing to it you did last time. Proxy processing is not based just on the URI; in the case of Route headers, the overall processing is the same only if the Route set through the loop has not changed. ************** No, we do need the route header for Proxy Servers. The record-route and route are used by the Proxy Server such that the Proxy server knows when the call is answered and disconnected in order to do billing ************** Mark Chiou One of the things we have now in bis is that a proxy computes, as part of the via branch ID, a hash of those things in the request that affect its processing. Effectively, if this includes a hash of the route set, there is no need to ensure that the URI in the route set are not identical. Realistically I expect they almost always would be anyway, though. I am beginning to wonder, however, whether or not this whole business of loop detection is worth the trouble. The Max-Forwards mechanism provides a sufficient way to ensure that they don't persist forever. The loop detection mecahnism is more efficient, but given the probability of occurence in a well-engineered network, I'm not sure its worth all the pain it causes, and it does cause pain. A proxy has to hash over a bunch of headers that it otherwise might be able to ignore... Anyone for deprecating loop detection? A proxy that doesn't do it would have to insert max-forwards if not already present, that is the penalty. We also need a minimum value for Max-Forwards, something like 20 is more than sufficient, I think. ************** Do I miss something, I thought the MAX-Forwards is used when a call is forwarded. In PSTN world, the default number allowing a call to be forwarded is 5. This means a call can only be forwarded (regarding any combination of forwarding flavor: CFU, CFB, CFNA, etc) up to 5 times. The Proxy Server shall check the max-Forward count before forwarding the call and increment max-Forward by one in the message toward the next Server. The loop detection is used when a call is ended up forwarded to itself. For example, A calls B and B CFU to C and C CFNA to A. ************** Mark Chiou This is has the nice side effect of making the branch ID just a pure transaction identifier, as it should be. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 13:22:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03528 for ; Tue, 8 Jan 2002 13:22:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13829 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 13:22:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13104; Tue, 8 Jan 2002 13:04:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13078 for ; Tue, 8 Jan 2002 13:04:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02857 for ; Tue, 8 Jan 2002 13:04:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08I4AVZ009488; Tue, 8 Jan 2002 13:04:12 -0500 (EST) Message-ID: <3C3B347B.8040505@dynamicsoft.com> Date: Tue, 08 Jan 2002 13:03:39 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: De Leo Walter CC: sip@ietf.org Subject: Re: [Sip] Basic questions. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Old email, not sure if it was answered, but the answers might be of interest to some. De Leo Walter wrote: > Excuse me I am new in this of SIP and have some basic questions whose > answers I couldnt find in the list digest. If this questions bother you, or > you think it is not the propper list to post them, please let me know, and > tell me where should I post them. > Here the questions: > 1) In SIPbis (04) the use of tags is mandatory for From headers, it was not > the case of RFC 2543, what is it required for?. To ensure that requests in the reverse direction do not get the tag accidentally added in the response. >(Call legs can be > distinguished by means of To tags (all other headers being equal). It would > have sense if URLs are removed (it was a Mr Rosemberg Proposal)from Call leg > identification but it is not the case yet, is it?) Since the selection of tag is a local implementation choice, you can always choose one uniquely enough to serve as a local dialog (aka call leg) identifier. However, other elements cannot count on this uniqueness property. > 2) More basic, what is the minimum length of a tag? There is none. Whatever is needed for ensure uniqueness. > 3) I have seen in one of the examples in the draft (the 20.5 forking > example) that a 200 response to a CANCEL didn't have a To tag. But the 487 > response to the INVITE being cancelled did include a To tag. Why is that. I > understand that the response to the CANCEL doesn't have a To Tag because the > call leg does not exist as the callee was not located. But why there is a To > Tag in the 487, is a short lifed call-leg created between caller and proxy? I believe that the implication of the new bis is that the CANCEL response would indeed have a tag now. We are trying to have a simple and uniform rule, which is that when you respond, you add a tag if there isn't one already there. This is method independent behavior and thus would apply to cancel. The to tag would presumably be the same as the to tag in the final response to the INVITE itself. > 4) Please don't laugh at me but I couldn't find out what is being referenced > when the draft sends you to [Hx.x]:( rfc2616 section x.x. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 13:27:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03752 for ; Tue, 8 Jan 2002 13:27:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13923 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 13:27:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13402; Tue, 8 Jan 2002 13:12:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13377 for ; Tue, 8 Jan 2002 13:12:00 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03094 for ; Tue, 8 Jan 2002 13:11:57 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08IBmVZ009491; Tue, 8 Jan 2002 13:11:50 -0500 (EST) Message-ID: <3C3B3643.3070002@dynamicsoft.com> Date: Tue, 08 Jan 2002 13:11:15 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Gurbani CC: SIP LIST Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-05 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Not sure I responded to this. Vijay Gurbani wrote: > First, here's what I think is missing from the R-R "magic", along with a > suggestion to make it complete. > > (1) Section 16.6, "Response processing", step 7, first paragraph: the > bis mentions that "... the proxy MAY choose to rewrite this value > before forwarding the response." but (as far as I can make out) > provides no guidance on how to rewrite this value. Note that > Section 16.5 provides guidance on how to use Contact (or From) + a > transaction identifier in a R-R header when it is being *inserted* > in a request. > > At the very least, section 16.6, "Response processing", step 7, > first paragraph can provide some information on how to rewrite > the value in an R-R response as follows: > > "If the selected response contained a Record-Route header field > originally inserted by this proxy, AND the proxy had modified > the request-URI when inserting the Record-Route, it MUST > substitue this value with the Request-URI of the initial request, > maintaining the maddr field and port field, before forwarding > the response." I do not advocate a MUST; there is much benefit in allowing a proxy to be flexible with the URL it can put in the RR header. I would be agreeable to including some guidelines in bullet 7 of 16.6 to mirror the guidelines present for requests. -Jonathan R. > (2) Provide an example, much as -04 bis did. I think that R-R rules > for re-writing R-URIs are complex enough that an example will go > a long way to ensure clarity, which will aid in interoperability. Not a bad idea. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 13:27:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03767 for ; Tue, 8 Jan 2002 13:27:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13938 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 13:27:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13454; Tue, 8 Jan 2002 13:12:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13425 for ; Tue, 8 Jan 2002 13:12:14 -0500 (EST) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03105 for ; Tue, 8 Jan 2002 13:12:11 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1986F.EAD88452" Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Tue, 8 Jan 2002 12:11:39 -0600 Message-ID: Thread-Topic: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Thread-Index: AcGYbGYu0BoEzBCoR0eX4b1Wwz225AAAtQRg From: "Chiou, Mark" To: "Lathan Lewis" , "Jonathan Rosenberg" , "Drage, Keith (Keith)" Cc: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C1986F.EAD88452 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would prefer to synchronize with legacy networks such that we won't break any existing network when we do interworking. Default value to 20 for Max-forwards is way too much.=20 =20 Mark Chiou Santera=20 -----Original Message----- From: Lathan Lewis [mailto:lathanl@nortelnetworks.com] Sent: Tuesday, January 08, 2002 11:40 AM To: 'Jonathan Rosenberg'; Drage, Keith (Keith) Cc: sip@ietf.org Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers I would agree with your proposal to deprecate loop detection based on=20 the fact that it is becoming more complex and expensive to implement than=20 it's worth. Our implementation currently relies on the Max-Forwards header=20 as you propose and is using a default value of 20.=20 Lathan Lewis=20 Nortel Networks=20 -----Original Message-----=20 From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com]=20 Sent: Tuesday, January 08, 2002 11:17 AM=20 To: Drage, Keith (Keith)=20 Cc: sip@ietf.org=20 Subject: Deprecate loop detection, was: Re: [Sip] bis draft:=20 Pre-existing Route headers=20 Drage, Keith (Keith) wrote:=20 > Section 8.1.1.7 of the bis draft (lines 948 through 952) appears to be the=20 > text that allows pre-existing Route headers to be used in the initial=20 > transaction of a dialogue, or in a stand-alone transaction.=20 >=20 > "8.1.1.7 Request-URI The initial Request-URI of the message SHOULD=20 > be set to the value of the URI in the To field. One notable exception is the=20 > REGISTER method; behavior for setting the Request-URI of register is given=20 > in Section 10. Another exception is the case of pre-existing Route headers;=20 > in that case, the procedures of Section 12.2.1.1 as they pertain to the=20 > Request- URI are followed, even though there is no dialog."=20 Right. We'll add a bit more text to explain what a "pre-existing route" is.=20 >=20 > A set of Route headers created using the Record-Route mechanism carries the=20 > mechanism to ensure that when the route traverses a spiral, all the URLs in=20 > the Record-Route headers are unique, and therefore that the set of Route=20 > headers is also unique.=20 Actually, I am not sure thats really needed anymore for routed requests. Here's why. Remember, the point of loop detection is to reject a request when you know that its processing will cause you do to the same thing to it you did last time. Proxy processing is not based just on the URI; in=20 the case of Route headers, the overall processing is the same only if=20 the Route set through the loop has not changed.=20 One of the things we have now in bis is that a proxy computes, as part=20 of the via branch ID, a hash of those things in the request that affect=20 its processing. Effectively, if this includes a hash of the route set,=20 there is no need to ensure that the URI in the route set are not=20 identical. Realistically I expect they almost always would be anyway,=20 though.=20 I am beginning to wonder, however, whether or not this whole business of loop detection is worth the trouble. The Max-Forwards mechanism provides a sufficient way to ensure that they don't persist forever. The loop=20 detection mecahnism is more efficient, but given the probability of=20 occurence in a well-engineered network, I'm not sure its worth all the=20 pain it causes, and it does cause pain. A proxy has to hash over a bunch of headers that it otherwise might be able to ignore...=20 Anyone for deprecating loop detection? A proxy that doesn't do it would=20 have to insert max-forwards if not already present, that is the penalty. We also need a minimum value for Max-Forwards, something like 20 is=20 more than sufficient, I think.=20 This is has the nice side effect of making the branch ID just a pure=20 transaction identifier, as it should be.=20 Comments?=20 -Jonathan R.=20 --=20 Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue=20 Chief Scientist First Floor=20 dynamicsoft East Hanover, NJ 07936=20 jdrosen@dynamicsoft.com FAX: (973) 952-5050=20 http://www.jdrosen.net PH: (973) 952-5000=20 http://www.dynamicsoft.com=20 _______________________________________________=20 Sip mailing list http://www1.ietf.org/mailman/listinfo/sip=20 This list is for NEW development of the core SIP Protocol=20 Use sip-implementors@cs.columbia.edu for questions on current sip=20 Use sipping@ietf.org for new developments on the application of sip=20 ------_=_NextPart_001_01C1986F.EAD88452 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Deprecate loop detection, was: Re: [Sip] bis draft: = Pre-existing Route headers
I=20 would prefer to synchronize with legacy networks such that we won't = break any=20 existing network when we do interworking.
Default value to 20 for Max-forwards is way = too=20 much. 
 
Mark=20 Chiou
Santera
-----Original Message-----
From: Lathan Lewis=20 [mailto:lathanl@nortelnetworks.com]
Sent: Tuesday, January = 08, 2002=20 11:40 AM
To: 'Jonathan Rosenberg'; Drage, Keith=20 (Keith)
Cc: sip@ietf.org
Subject: RE: Deprecate = loop=20 detection, was: Re: [Sip] bis draft: Pre-existing Route=20 headers


I would agree with your proposal to deprecate loop = detection=20 based on
the fact that it is becoming more = complex and=20 expensive to implement than
it's worth. Our=20 implementation currently relies on the Max-Forwards header =
as you propose and is using a default value of 20. =

Lathan Lewis
Nortel = Networks=20

-----Original Message-----
From:=20 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20
Sent: Tuesday, January 08, 2002 11:17 AM =
To: Drage, Keith (Keith)
Cc:=20 sip@ietf.org
Subject: Deprecate loop = detection, was:=20 Re: [Sip] bis draft:
Pre-existing Route = headers=20




Drage, Keith (Keith) wrote:

> Section 8.1.1.7 of the bis draft (lines 948 = through 952)=20 appears to be the
> text that allows = pre-existing=20 Route headers to be used in the initial
> = transaction of a dialogue, or in a stand-alone transaction. =
>
> =      =20 "8.1.1.7 Request-URI The initial Request-URI of the message = SHOULD=20
> be set to the value of the URI in the To = field. One=20 notable exception is the
> REGISTER = method;=20 behavior for setting the Request-URI of register is given =
> in Section 10. Another exception is the case of = pre-existing Route=20 headers;
> in that case, the procedures = of Section=20 12.2.1.1 as they pertain to the
> = Request- URI are=20 followed, even though there is no dialog."


Right. We'll add a bit more text to explain what a=20 "pre-existing route" is.


>
> A set of Route = headers=20 created using the Record-Route mechanism carries the
> mechanism to ensure that when the route traverses a = spiral, all=20 the URLs in
> the Record-Route headers = are unique,=20 and therefore that the set of Route
> = headers is=20 also unique.


Actually, I am not sure thats really needed anymore = for routed=20 requests.
Here's why. Remember, the point of = loop=20 detection is to reject a request
when you = know that=20 its processing will cause you do to the same thing to
it you did last time. Proxy processing is not based just on = the URI; in=20
the case of Route headers, the overall = processing is=20 the same only if
the Route set through the = loop has=20 not changed.

One of the things we have now in bis is that a proxy = computes,=20 as part
of the via branch ID, a hash of = those things=20 in the request that affect
its processing.=20 Effectively, if this includes a hash of the route set, =
there is no need to ensure that the URI in the route set are = not=20
identical. Realistically I expect they = almost always=20 would be anyway,
though.

I am beginning to wonder, however, whether or not = this whole=20 business of
loop detection is worth the = trouble. The=20 Max-Forwards mechanism provides
a sufficient = way to=20 ensure that they don't persist forever. The loop
detection mecahnism is more efficient, but given the = probability of=20
occurence in a well-engineered network, I'm = not sure=20 its worth all the
pain it causes, and it = does cause=20 pain. A proxy has to hash over a bunch
of = headers that=20 it otherwise might be able to ignore...

Anyone for deprecating loop detection? A proxy that = doesn't do=20 it would
have to insert max-forwards if not = already=20 present, that is the penalty.
  We also = need a=20 minimum value for Max-Forwards, something like 20 is
more than sufficient, I think.

This is has the nice side effect of making the = branch ID just=20 a pure
transaction identifier, as it should = be.=20

Comments?

-Jonathan R.



--
Jonathan D. Rosenberg,=20 = Ph.D.            = 72=20 Eagle Rock Avenue
Chief=20 = Scientist          &nbs= p;            = ; =20 First Floor
dynamicsoft         = ;            =        =20 East Hanover, NJ 07936
jdrosen@dynamicsoft.com       = ;         =20 FAX: (973) 952-5050
http://www.jdrosen.net     &= nbsp;           =20 PH:  (973) 952-5000
http://www.dynamicsoft.com


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

------_=_NextPart_001_01C1986F.EAD88452-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 13:58:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05100 for ; Tue, 8 Jan 2002 13:58:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15484 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 13:58:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14005; Tue, 8 Jan 2002 13:28:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13975 for ; Tue, 8 Jan 2002 13:28:49 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03823 for ; Tue, 8 Jan 2002 13:28:47 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g08ISYK03655; Tue, 8 Jan 2002 19:28:34 +0100 (MET) Received: from lmf.ericsson.se (lmf05397pc.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g08ISXhO008289; Tue, 8 Jan 2002 20:28:33 +0200 (EET) Message-ID: <3C3B3A58.BE3295EC@lmf.ericsson.se> Date: Tue, 08 Jan 2002 20:28:40 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Chiou, Mark" CC: Jonathan Rosenberg , "Drage, Keith (Keith)" , sip@ietf.org Subject: Re: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >************** >No, we do need the route header for Proxy Servers. The record-route and >route are used by the Proxy Server such that the Proxy server knows when >the call is answered and disconnected in order to do billing >************** Mark Chiou Maybe I don't get the point, but why do you need the Route and Record-Route headers to know when a call is answered and disconnected? >************** >Do I miss something, I thought the MAX-Forwards is used when a call is >forwarded. In PSTN world, the default number allowing a call to be >forwarded is 5. This means a call can only be forwarded (regarding any >combination of forwarding flavor: CFU, CFB, CFNA, etc) up to 5 times. >The Proxy Server shall check the max-Forward count before forwarding the >call and increment max-Forward by one in the message toward the next >Server. In SIP the MAX-Forwards value is DECREASED by one by proxies. When it reaches zero, an error response is then sent back to the sender. >The loop detection is used when a call is ended up forwarded to itself. >For example, A calls B and B CFU to C and C CFNA to A. >************** Mark Chiou Yes, but what we are discussing here is if the loop detection mechanism used by proxies is needed or not. If a client (in your case A) initiates the call, and it is routed back to that client, that mechanism is not needed to detect the loop. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:00:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05152 for ; Tue, 8 Jan 2002 14:00:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15563 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:00:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14648; Tue, 8 Jan 2002 13:38:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14616 for ; Tue, 8 Jan 2002 13:38:15 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04213 for ; Tue, 8 Jan 2002 13:38:13 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GPM00501UCTGM@firewall.wcom.com> for sip@ietf.org; Tue, 8 Jan 2002 18:36:29 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GPM00541UCT42@firewall.wcom.com>; Tue, 08 Jan 2002 18:36:29 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GPM00901UCQQ8@dgismtp04.wcomnet.com>; Tue, 08 Jan 2002 18:36:29 +0000 (GMT) Received: from hsinnreich2 ([166.35.225.146]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GPM0085UUC602@dgismtp04.wcomnet.com>; Tue, 08 Jan 2002 18:36:12 +0000 (GMT) Date: Tue, 08 Jan 2002 12:36:04 -0600 From: Henry Sinnreich Subject: RE: [Sip] Default value for Timer C (was #282) In-reply-to: <61D824C63B99D311975E00508B0CC98502C66D4B@eamrcnt717.exu.ericsson.se> To: adam.roach@ericsson.com, "'Robert Sparks'" , John.Hearty@Level3.com, taylor@nortelnetworks.com, wtm@research.att.com, sip@ietf.org Message-id: <001001c19873$58057c20$92e123a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Everyone please > inhale deeply, exhale slowly, and repeat to yourself: "This is not > the PSTN. This is not the PSTN. This is not the PSTN." Yesss!!! Henry Sinnreich WorldCom > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > adam.roach@ericsson.com > Sent: Tuesday, January 08, 2002 11:20 AM > To: 'Robert Sparks'; John.Hearty@Level3.com; taylor@nortelnetworks.com; > wtm@research.att.com; sip@ietf.org > Subject: RE: [Sip] Default value for Timer C (was #282) > > I know I'm entering this thread late (I'm a bit behind on the list), > but I just *need* to object. > > In particular, if we accept Robert's concession, this consensus makes > the 182 status code almost completely worthless. > > This *isn't* a TDM architecture, and treating it as such is ridiculous. > I was under the impression that everyone here understood that billing > based on SIP signaling is a rather ridiculous proposition; given that, > it should be obvious that remaining in a pre-answer state isn't any sort > of an attempt to "cheat." It's obviously someone using the basic building > blocks of SIP in a way that you may not have conceived in order to > provide some service -- and I thought that's what the protocol was all > about. > > Staying in a pre-answer state has several legitimate uses. Sending of > 182 messages is one of the most obvious ("SIP/2.0 182 Call is queued; > approximate wait is 13 minutes"), since it is endorsed by the > specification itself. Robert has pointed out another real-world > application (which happens to involve legacy systems). > > So, there's the theoretical problem to satisfy the purists, and > the actual "someone you know has personally been inconvenienced > by this" problem to satisfy those swayed by anecdotes: an arbitrary > short limit on pre-answer states creates a real problem. > > There have already been proposals about how to work around this (e.g. > re-sending provisional responses periodically), so I don't believe the > impasse is technical in nature. > > That means we have a philosophical difference here. Everyone please > inhale deeply, exhale slowly, and repeat to yourself: "This is not > the PSTN. This is not the PSTN. This is not the PSTN." Then examine > the problem from a SIP perspective. Keep the whole "generality" thing > in mind, and consider whether you want to limit the number of services > and the ways they can be implemented. > > /a > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:06:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05589 for ; Tue, 8 Jan 2002 14:06:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16276 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:06:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14905; Tue, 8 Jan 2002 13:43:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14762 for ; Tue, 8 Jan 2002 13:43:15 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04494 for ; Tue, 8 Jan 2002 13:43:12 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g08Iggx04385; Tue, 8 Jan 2002 13:42:42 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA07241; Tue, 8 Jan 2002 12:42:41 -0600 (CST) Message-ID: <3C3B3D89.79FA6132@lucent.com> Date: Tue, 08 Jan 2002 12:42:17 -0600 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: SIP LIST Subject: Re: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers References: <3C3B296F.4010401@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] > I am beginning to wonder, however, whether or not this whole business of > loop detection is worth the trouble. The Max-Forwards mechanism provides > a sufficient way to ensure that they don't persist forever. The loop > detection mecahnism is more efficient, but given the probability of > occurence in a well-engineered network, I'm not sure its worth all the > pain it causes, and it does cause pain. A proxy has to hash over a bunch > of headers that it otherwise might be able to ignore... > > Anyone for deprecating loop detection? Deprecating is fine since it has the side effect of making the branch ID a pure transaction identifier. I don't think it will have any effect on spiraling -- in fact, if the branch ID is a pure transaction identifier, a spiral will simply be counted as a new transaction (simply based on the branch ID in the topmost Via) at the receiving SIP server. Only thing we loose is that at least with loop detection, unwanted requests are discarded right away, instead of lingering in the network for a while. > A proxy that doesn't do it would have to insert max-forwards if not > already present, that is the penalty. I sense an ambiguity here in reading and parsing your statement -- are you saying that proxies should either (a) do loop detection, OR (b) insert a Max-Forwards if not present? If so, I really think providing this choice will be a nightmare. -06bis should simply not mention loop detection and state that a proxy MUST add a Max-Forwards header to downstream requests, if one was not present already. Of course, the 482 response code should be maintained for backward compatibility. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:06:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05595 for ; Tue, 8 Jan 2002 14:06:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16291 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:06:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14934; Tue, 8 Jan 2002 13:43:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14761 for ; Tue, 8 Jan 2002 13:43:15 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04486 for ; Tue, 8 Jan 2002 13:42:50 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g08IgbJ19601; Tue, 8 Jan 2002 19:42:37 +0100 (MET) Received: from lmf.ericsson.se (lmf05397pc.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g08IgbhO008601; Tue, 8 Jan 2002 20:42:37 +0200 (EET) Message-ID: <3C3B3DA3.E87C48C9@lmf.ericsson.se> Date: Tue, 08 Jan 2002 20:42:43 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Drage, Keith (Keith)" , sip@ietf.org Subject: Re: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers References: <3C3B296F.4010401@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >Anyone for deprecating loop detection? A proxy that doesn't do it would >have to insert max-forwards if not already present, that is the penalty. >We also need a minimum value for Max-Forwards, something like 20 is >more than sufficient, I think. Do we need to specify a minimum value in the spec? I think the value is something which is very dependent on the size and architechture of the network, and should be configurable. Also, are proxies allowed to change the value? For example, I may use 100 when I call from my SIP phone, but an administration proxy in my SIP network may then decrease it to whatever value. Also, if I call from network A to network B, network B's "border proxy" may also choose to change the value when it receives the request. Also, IF we choose to only use the MAX-Forwards header, I guess we would have to make it MANDATORY - or at least make it mandatory for a proxy to insert the header if it receives a request without it? Otherwise I don't have anything against the proposal. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:11:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05801 for ; Tue, 8 Jan 2002 14:11:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16494 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:11:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15102; Tue, 8 Jan 2002 13:48:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15071 for ; Tue, 8 Jan 2002 13:48:55 -0500 (EST) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04672 for ; Tue, 8 Jan 2002 13:48:53 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Tue, 8 Jan 2002 12:48:21 -0600 Message-ID: Thread-Topic: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Thread-Index: AcGYcknOqX3TZeG1QxKcH/54Zds3gQAAI1ug From: "Chiou, Mark" To: "Christer Holmberg" Cc: "Jonathan Rosenberg" , "Drage, Keith (Keith)" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA15072 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, The reason to use Record-route and Route is to ensure the Proxy Server to receive all the SIP request/response messages. You know without Record-route and Route, the ACK request can go different route such that a Proxy Server won't be able to capture the answer time. The same reason for capturing disconnect time when UAC and UAS release (i.e. BYE request) the call. The Max-forwards is decreased by one is fine as long as it can be used when interworking with PSTN call forwarding features. We are talking the same thing. proxy does need a loop detection mechanism. Mark Chiou Santera Systems -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Tuesday, January 08, 2002 12:29 PM To: Chiou, Mark Cc: Jonathan Rosenberg; Drage, Keith (Keith); sip@ietf.org Subject: Re: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Hi, >************** >No, we do need the route header for Proxy Servers. The record-route and >route are used by the Proxy Server such that the Proxy server knows when >the call is answered and disconnected in order to do billing >************** Mark Chiou Maybe I don't get the point, but why do you need the Route and Record-Route headers to know when a call is answered and disconnected? >************** >Do I miss something, I thought the MAX-Forwards is used when a call is >forwarded. In PSTN world, the default number allowing a call to be >forwarded is 5. This means a call can only be forwarded (regarding any >combination of forwarding flavor: CFU, CFB, CFNA, etc) up to 5 times. >The Proxy Server shall check the max-Forward count before forwarding the >call and increment max-Forward by one in the message toward the next >Server. In SIP the MAX-Forwards value is DECREASED by one by proxies. When it reaches zero, an error response is then sent back to the sender. >The loop detection is used when a call is ended up forwarded to itself. >For example, A calls B and B CFU to C and C CFNA to A. >************** Mark Chiou Yes, but what we are discussing here is if the loop detection mechanism used by proxies is needed or not. If a client (in your case A) initiates the call, and it is routed back to that client, that mechanism is not needed to detect the loop. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:21:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06246 for ; Tue, 8 Jan 2002 14:21:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16917 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:21:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15474; Tue, 8 Jan 2002 13:58:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15445 for ; Tue, 8 Jan 2002 13:58:53 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05095 for ; Tue, 8 Jan 2002 13:58:51 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A16A1AA2003C; Tue, 08 Jan 2002 13:58:50 -0500 Message-ID: <009f01c19876$1d2966e0$2300000a@acmepacket.com> From: "Bob Penfield" To: , "'Robert Sparks'" , , , , References: <61D824C63B99D311975E00508B0CC98502C66D4B@eamrcnt717.exu.ericsson.se> Subject: Re: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 13:56:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit OK ... This is not the PSTN. This is not the PSTN. This is not the PSTN. I do think it is not wise to have an extremely large default Timer C value. I'm thinking 3 minutes is about right. There needs to be some mechanism that allows a UAS that is putting a call in queue to tell the intervening proxies that it will take longer than the default Timer C to answer the call. The UAC has no way of knowing how long the UAS will take to answer, so I don't think using the Expires value in the INVITE to affect Timer C will help much. Two ways of doing this come to mind: 1) Modify the FSMs to restart Timer C for every 1xx response and then have the UAS send a 1xx periodically to maintain the transactions in the proxies. 2) Include the "expected time" the UAS will take to answer the call in the 1xx response and the proxies would set their Timer C accordingly. This would still require the UAS to retransmit the 1xx response if the call was not answered in time, but the proxies would only have to reset the timer when they saw the "expected time" value. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: To: "'Robert Sparks'" ; ; ; ; Sent: Tuesday, January 08, 2002 12:19 PM Subject: RE: [Sip] Default value for Timer C (was #282) > I know I'm entering this thread late (I'm a bit behind on the list), > but I just *need* to object. > > In particular, if we accept Robert's concession, this consensus makes > the 182 status code almost completely worthless. > > This *isn't* a TDM architecture, and treating it as such is ridiculous. > I was under the impression that everyone here understood that billing > based on SIP signaling is a rather ridiculous proposition; given that, > it should be obvious that remaining in a pre-answer state isn't any sort > of an attempt to "cheat." It's obviously someone using the basic building > blocks of SIP in a way that you may not have conceived in order to > provide some service -- and I thought that's what the protocol was all > about. > > Staying in a pre-answer state has several legitimate uses. Sending of > 182 messages is one of the most obvious ("SIP/2.0 182 Call is queued; > approximate wait is 13 minutes"), since it is endorsed by the > specification itself. Robert has pointed out another real-world > application (which happens to involve legacy systems). > > So, there's the theoretical problem to satisfy the purists, and > the actual "someone you know has personally been inconvenienced > by this" problem to satisfy those swayed by anecdotes: an arbitrary > short limit on pre-answer states creates a real problem. > > There have already been proposals about how to work around this (e.g. > re-sending provisional responses periodically), so I don't believe the > impasse is technical in nature. > > That means we have a philosophical difference here. Everyone please > inhale deeply, exhale slowly, and repeat to yourself: "This is not > the PSTN. This is not the PSTN. This is not the PSTN." Then examine > the problem from a SIP perspective. Keep the whole "generality" thing > in mind, and consider whether you want to limit the number of services > and the ways they can be implemented. > > /a > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:28:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06538 for ; Tue, 8 Jan 2002 14:28:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17120 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:28:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16205; Tue, 8 Jan 2002 14:04:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16177 for ; Tue, 8 Jan 2002 14:04:24 -0500 (EST) Received: from redmailwall3.attws.com (redmailwall3.attws.com [199.108.253.114]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05418 for ; Tue, 8 Jan 2002 14:04:22 -0500 (EST) Received: from viruswall.entp.attws.com (viruswall [135.214.42.163]) by redmailwall3.attws.com (8.10.2+Sun/8.9.3) with ESMTP id g08J3hi29814; Tue, 8 Jan 2002 11:03:43 -0800 (PST) Received: from nwestmail.entp.attws.com by viruswall.entp.attws.com (8.10.2+Sun/AT&T Wireless Services, Inc.) id g08J3jb09793; Tue, 8 Jan 2002 11:03:45 -0800 (PST) Received: from wa-msg01.entp.attws.com (wa-msg01.entp.attws.com [135.214.41.60]) by nwestmail.entp.attws.com (8.8.8+Sun/8.8.8) with ESMTP id LAA00246; Tue, 8 Jan 2002 11:03:43 -0800 (PST) Received: by WA-MSG01 with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 11:03:43 -0800 Message-ID: <1F559B7B150DD411A62F00508B9557EC0BF07A94@WA-MSG01> From: "Shieh, Hugh" To: "'Alan O'Neill'" , "'William Marshall'" , "'sip@ietf.org'" Subject: RE: [Sip] Still issues with preconditions Date: Tue, 8 Jan 2002 11:03:35 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19877.2C4D05E0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19877.2C4D05E0 Content-Type: text/plain Comments inline. -----Original Message----- From: Alan O'Neill [mailto:A.ONeill@flarion.com] Sent: Tuesday, January 08, 2002 4:49 AM To: William Marshall; sip@ietf.org Subject: RE: [Sip] Still issues with preconditions Thanks for the response Bill Comments in-line -----Original Message----- From: William Marshall [mailto:wtm@research.att.com] Sent: 27 December 2001 17:16 To: sip@ietf.org Subject: Re: [Sip] Still issues with preconditions Snipped... Should additional terms be defined in manyfolks draft, such as "access" and "backbone" to enable this vertical split? Second, are these the right terms? Comments? AWO> In all cases, the user software should be aware of how it can respond to offered preconditions given its QoS capabilities and its SLA with its operator. This response should be outside the preconditions draft and should instead be in a document discussing the mapping between preconditions and network QoS mechanisms and topologies. The draft should continue to include the simplified horizontal example whilst these mappings are agreed in my book... Hugh> The actual QoS mechanisms are outside the scope of this draft, however, I believe the definition of preconditions is within the scope. As Bill pointed out that the existing definition in the draft (sendonly, recvonly, sendrecv) assumes the horizontal end-to-end model. I see the value of defining the precondition for the vertical model in the draft (to avoid future interoperability problem). In some network, there are "access" and "backbone", the resource in the "backbone" can be statistically provisioned with possibility of semi-dynamic reconfiguration, and the "backbone" resource may not be reserved at per call basis. However, the resource in the "access" part of the network need be reserved at per call basis (e.g., 3G wireless). In this case, UA can only know and need only know if the "access" part of precondition can be satisfied. I would support to define an "access" precondition in the draft. -Hugh Snipped... ------_=_NextPart_001_01C19877.2C4D05E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] Still issues with preconditions

Comments inline.

-----Original Message-----
From: Alan O'Neill [mailto:A.ONeill@flarion.com] =
Sent: Tuesday, January 08, 2002 4:49 AM
To: William Marshall; sip@ietf.org
Subject: RE: [Sip] Still issues with = preconditions

Thanks for the response Bill

Comments in-line

-----Original Message-----
From: William Marshall [mailto:wtm@research.att.com]
Sent: 27 December 2001 17:16
To: sip@ietf.org
Subject: Re: [Sip] Still issues with = preconditions

Snipped...

Should additional terms be defined in manyfolks = draft, such as "access"
and "backbone" to enable this vertical = split?  Second, are these the
right terms?  Comments?

AWO> In all cases, the user software should be = aware of how it can respond
to offered preconditions given its QoS capabilities = and its SLA with its
operator. This response should be outside the = preconditions draft and should
instead be in a document discussing the mapping = between preconditions and
network QoS mechanisms and topologies. The draft = should continue to include
the simplified horizontal example whilst these = mappings are agreed in my
book...

Hugh> The actual QoS mechanisms are outside the = scope of this draft, however, I believe the definition of preconditions = is within the scope. As Bill pointed out that the existing definition = in the draft (sendonly, recvonly, sendrecv) assumes the horizontal = end-to-end model. I see the value of defining the precondition for the = vertical model in the draft (to avoid future interoperability problem). = In some network, there are "access" and "backbone", = the resource in the "backbone" can be statistically = provisioned with possibility of semi-dynamic reconfiguration, and the = "backbone" resource may not be reserved at per call basis. = However, the resource in the "access" part of the network = need be reserved at per call basis (e.g., 3G wireless). In this case, = UA can only know and need only know if the "access" part of = precondition can be satisfied. I would support to define an = "access" precondition in the draft.

-Hugh

Snipped...

------_=_NextPart_001_01C19877.2C4D05E0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:31:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06788 for ; Tue, 8 Jan 2002 14:31:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17702 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:31:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16357; Tue, 8 Jan 2002 14:07:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16330 for ; Tue, 8 Jan 2002 14:07:51 -0500 (EST) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05650 for ; Tue, 8 Jan 2002 14:07:49 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Default value for Timer C (was #282) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Tue, 8 Jan 2002 13:07:20 -0600 Message-ID: Thread-Topic: [Sip] Default value for Timer C (was #282) Thread-Index: AcGYdR/yZOuPFtGHTDKoFYbMcInmaQAAaoRQ From: "Chiou, Mark" To: "Henry Sinnreich" , , "Robert Sparks" , , , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA16331 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I agree this is not a PSTN, but don't forget the whole world is not all IP yet. Please think about Cellular networks as an example, there are still a large portion of the calls interworking with PSTN networks. The same scenario will be occurred for IP. We CANNOT exclude the legacy networks at all. A penny worth thought, Mark Chiou Santera -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] Sent: Tuesday, January 08, 2002 12:36 PM To: adam.roach@ericsson.com; 'Robert Sparks'; John.Hearty@Level3.com; taylor@nortelnetworks.com; wtm@research.att.com; sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) > Everyone please > inhale deeply, exhale slowly, and repeat to yourself: "This is not > the PSTN. This is not the PSTN. This is not the PSTN." Yesss!!! Henry Sinnreich WorldCom > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > adam.roach@ericsson.com > Sent: Tuesday, January 08, 2002 11:20 AM > To: 'Robert Sparks'; John.Hearty@Level3.com; taylor@nortelnetworks.com; > wtm@research.att.com; sip@ietf.org > Subject: RE: [Sip] Default value for Timer C (was #282) > > I know I'm entering this thread late (I'm a bit behind on the list), > but I just *need* to object. > > In particular, if we accept Robert's concession, this consensus makes > the 182 status code almost completely worthless. > > This *isn't* a TDM architecture, and treating it as such is ridiculous. > I was under the impression that everyone here understood that billing > based on SIP signaling is a rather ridiculous proposition; given that, > it should be obvious that remaining in a pre-answer state isn't any sort > of an attempt to "cheat." It's obviously someone using the basic building > blocks of SIP in a way that you may not have conceived in order to > provide some service -- and I thought that's what the protocol was all > about. > > Staying in a pre-answer state has several legitimate uses. Sending of > 182 messages is one of the most obvious ("SIP/2.0 182 Call is queued; > approximate wait is 13 minutes"), since it is endorsed by the > specification itself. Robert has pointed out another real-world > application (which happens to involve legacy systems). > > So, there's the theoretical problem to satisfy the purists, and > the actual "someone you know has personally been inconvenienced > by this" problem to satisfy those swayed by anecdotes: an arbitrary > short limit on pre-answer states creates a real problem. > > There have already been proposals about how to work around this (e.g. > re-sending provisional responses periodically), so I don't believe the > impasse is technical in nature. > > That means we have a philosophical difference here. Everyone please > inhale deeply, exhale slowly, and repeat to yourself: "This is not > the PSTN. This is not the PSTN. This is not the PSTN." Then examine > the problem from a SIP perspective. Keep the whole "generality" thing > in mind, and consider whether you want to limit the number of services > and the ways they can be implemented. > > /a > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:38:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07119 for ; Tue, 8 Jan 2002 14:38:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18027 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:38:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16655; Tue, 8 Jan 2002 14:15:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16624 for ; Tue, 8 Jan 2002 14:15:46 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05985 for ; Tue, 8 Jan 2002 14:15:44 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08JFfVZ009534; Tue, 8 Jan 2002 14:15:42 -0500 (EST) Message-ID: <3C3B453D.1090903@dynamicsoft.com> Date: Tue, 08 Jan 2002 14:15:09 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Chiou, Mark" CC: "Drage, Keith (Keith)" , sip@ietf.org Subject: Re: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-exist ing Route headers References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chiou, Mark wrote: > Please see comments inline. Thanks, Mark Chiou > > it you did last time. Proxy processing is not based just on the URI; in > the case of Route headers, the overall processing is the same only if > the Route set through the loop has not changed. > > ************** > No, we do need the route header for Proxy Servers. The record-route and > route are used by the Proxy Server such that the Proxy server knows when > the call is answered and disconnected in order to do billing > ************** Mark Chiou The proposal was not to deprecate route or record-route, just loop detection. Oh, and, as an unrelated side note, good luck billing for calls based on duration in a proxy. THere are so many fraud attacks I could write a book on just that subject. I'd make a fortune! If you tell me which customers are using this, I would like to know so I can make lots of free phone calls. [ps, if you want to respond to this, please do so in a separate thread or privately so we do not detract from the point here] > ************** > Do I miss something, I thought the MAX-Forwards is used when a call is > forwarded. In PSTN world, the default number allowing a call to be > forwarded is 5. This means a call can only be forwarded (regarding any > combination of forwarding flavor: CFU, CFB, CFNA, etc) up to 5 times. > The Proxy Server shall check the max-Forward count before forwarding the > call and increment max-Forward by one in the message toward the next > Server. > The loop detection is used when a call is ended up forwarded to itself. > For example, A calls B and B CFU to C and C CFNA to A. > ************** Mark Chiou Max-Forwards counts the number of proxy hops. Each hop may or may not forward a call to a separate subscriber in the PSTN sense. It needs to be large enough to span a large SIP network. In 3g, i think a mobile to mobile call would be like ten or so, possibly more... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:40:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07199 for ; Tue, 8 Jan 2002 14:40:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18082 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:40:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16713; Tue, 8 Jan 2002 14:17:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16679 for ; Tue, 8 Jan 2002 14:17:24 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06049 for ; Tue, 8 Jan 2002 14:17:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08JHNVZ009540; Tue, 8 Jan 2002 14:17:23 -0500 (EST) Message-ID: <3C3B45A3.9040508@dynamicsoft.com> Date: Tue, 08 Jan 2002 14:16:51 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Gurbani CC: SIP LIST Subject: Re: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-exist ing Route headers References: <3C3B3D89.79FA6132@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Vijay Gurbani wrote: > Jonathan Rosenberg wrote: > Deprecating is fine since it has the side effect of making the branch ID > a > pure transaction identifier. I don't think it will have any effect on > spiraling -- in fact, if the branch ID is a pure transaction identifier, > a spiral will simply be counted as a new transaction (simply based on > the > branch ID in the topmost Via) at the receiving SIP server. Right. > > Only thing we loose is that at least with loop detection, unwanted > requests > are discarded right away, instead of lingering in the network for a > while. Right. This is what I meant by loop detection being more efficient than max-forwards, but the cost is high. > > >>A proxy that doesn't do it would have to insert max-forwards if not >>already present, that is the penalty. >> > > I sense an ambiguity here in reading and parsing your statement -- are > you > saying that proxies should either (a) do loop detection, OR (b) insert a > > Max-Forwards if not present? No, my apologies. The "penalty" here is additional specification text and required behavior of a proxy. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:47:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07443 for ; Tue, 8 Jan 2002 14:47:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18319 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:47:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17026; Tue, 8 Jan 2002 14:25:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16995 for ; Tue, 8 Jan 2002 14:25:07 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06420 for ; Tue, 8 Jan 2002 14:25:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08JORVZ009553; Tue, 8 Jan 2002 14:24:27 -0500 (EST) Message-ID: <3C3B474B.4050609@dynamicsoft.com> Date: Tue, 08 Jan 2002 14:23:55 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: "Drage, Keith (Keith)" , sip@ietf.org Subject: Re: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-exist ing Route headers References: <3C3B3DA3.E87C48C9@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > >>Anyone for deprecating loop detection? A proxy that doesn't do it would >>have to insert max-forwards if not already present, that is the >> > penalty. > >>We also need a minimum value for Max-Forwards, something like 20 is >>more than sufficient, I think. >> > > Do we need to specify a minimum value in the spec? I think the value is > something which is very dependent on the size and architechture of the > network, and should be configurable. That is a recipe for disaster. Big disasters. Remember, calls go between domains that are frequently not in any kind of business relationship. I have no way of knowing what kind of network is downstream. So, we choose a value which is sufficiently large to cover all realistic cases. Having it configurable means it could be right today, but wrong tomorrow. Shall I have all my customers support calls get forwarded to you, Christer, so you can explain why a call yesterday won't work today because a different network provider installed a new proxy? > > Also, are proxies allowed to change the value? For example, I may use > 100 when I call from my SIP phone, but an administration proxy in my SIP > network may then decrease it to whatever value. Also, if I call from > network A to network B, network B's "border proxy" may also choose to > change the value when it receives the request. Yes, they can change it. But you need to be careful in that, if a proxy always ups it on every loop through it you get no protection at all. Really, it should only ever lower it, and only for very good reason. We should think about adding that to the spec. > > Also, IF we choose to only use the MAX-Forwards header, I guess we would > have to make it MANDATORY - or at least make it mandatory for a proxy to > insert the header if it receives a request without it? That is what I proposed, yes. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 14:56:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07944 for ; Tue, 8 Jan 2002 14:56:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18657 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 14:56:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17218; Tue, 8 Jan 2002 14:28:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17192 for ; Tue, 8 Jan 2002 14:28:46 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06596 for ; Tue, 8 Jan 2002 14:28:44 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08JSQVZ009559; Tue, 8 Jan 2002 14:28:26 -0500 (EST) Message-ID: <3C3B483A.2040001@dynamicsoft.com> Date: Tue, 08 Jan 2002 14:27:54 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] m= lines with multiple ports Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > More on the SIP media handling discussion. > > At the moment, I think most people agree that the number of m= lines in > the request and response MUST match. > > Now, SDP allows the including of multiple ports (so called port pairs) > in a single m= line, so the UAC may send: > > m=audio 2000/2 RTP/AVP 31 This is for hierarchically layered video, typically used with multicast. I don't think there is any use for unicast. > > Now, there are a few scenarios: > > 1. The UAS only supports the stream on one port. In that case, it could > indicate that by sending: > > m=audio 3000 RTP/AVP 31 > m=audio 0 RTP/AVP 31 > > However, this breaks the matching rule... Christer, you are inventing problems. The response to this would mirror the same m line since its multicast. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 15:04:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08340 for ; Tue, 8 Jan 2002 15:04:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19659 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 15:04:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17985; Tue, 8 Jan 2002 14:37:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17884 for ; Tue, 8 Jan 2002 14:37:05 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07050 for ; Tue, 8 Jan 2002 14:37:03 -0500 (EST) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g08JYVJ21772; Tue, 8 Jan 2002 13:34:31 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g08JYUh07226; Tue, 8 Jan 2002 13:34:30 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id NAA03639; Tue, 8 Jan 2002 13:34:30 -0600 (CST) Reply-To: To: "'Bob Penfield'" , , "'Robert Sparks'" , , , , Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 13:34:28 -0600 Message-ID: <61D824C63B99D311975E00508B0CC98502C66D50@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <009f01c19876$1d2966e0$2300000a@acmepacket.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > 1) Modify the FSMs to restart Timer C for every 1xx response > and then have > the UAS send a 1xx periodically to maintain the transactions > in the proxies. > > 2) Include the "expected time" the UAS will take to answer > the call in the > 1xx response and the proxies would set their Timer C > accordingly. This would > still require the UAS to retransmit the 1xx response if the > call was not > answered in time, but the proxies would only have to reset > the timer when > they saw the "expected time" value. I like both of these solutions (it was the first one to which I was referring in my previous mail), and have no preference between them. /a _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 15:07:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08526 for ; Tue, 8 Jan 2002 15:07:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19729 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 15:07:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18199; Tue, 8 Jan 2002 14:44:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18174 for ; Tue, 8 Jan 2002 14:44:00 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07366 for ; Tue, 8 Jan 2002 14:43:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08JhSVZ009585; Tue, 8 Jan 2002 14:43:28 -0500 (EST) Message-ID: <3C3B4BC0.2070801@dynamicsoft.com> Date: Tue, 08 Jan 2002 14:42:56 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'Jonathan Lennox'" , sip@ietf.org Subject: Re: [Sip] bis draft: Headers in 100 Trying (was "Minor NIT on Sup ported header") Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: >>>Does anybody see any purpose for any headers other than From; To; >>> >>Call-ID; >> >>>CSeq; Via; and Content-Length within a 100 Trying response. >>> >>In addition to the two Vijay mentioned (Server and Timestamp), I don't see >>anything wrong with including Date. Some servers, including ours, insert >>it >>in every message generated. (In a 100 it's probably roughly as useful as >>Server, i.e. it's good for debugging and for diagnosing various abnormal >>situations.) >> >> > See previous mail concerning why I think Server and Timestamp are not > applicable. Having reread the bis draft concerning Date, I can see that this > is applicable. Timestamp is most definitely applicable to 100, as this is the only response it is useful for. > > >>Bis says that Record-Route headers MAY be present in a provisional >>response, >>and doesn't separate out 100 Trying from other 1xx responses. I can >>imagine scenarios where Record-Route in a 100 could be useful, but I'm not >>sure how plausible they are. >> >> > Yes, I can see that the current rules allow a proxy to respond. This would > only appear to have any impact on the call from a 1st proxy back to a UAC, > as it is only the UAC that sent the request in the first place that can use > the accumulated Record-Route information. Now I am stuck to see how useful > that usage is. I do not think Record-Route or Contact is appropriate in 100. According to bis-05, it is actually allowed, since the spec says that 1xx/2xx to INVITE create dialogs, and dialog-creating responses have those things. However, I believe this to be an error in the spec, and that rather, 101-199/2xx to INVITE create dialogs. We will fix this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 15:07:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08524 for ; Tue, 8 Jan 2002 15:07:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19715 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 15:07:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18388; Tue, 8 Jan 2002 14:48:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18359 for ; Tue, 8 Jan 2002 14:48:52 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07540 for ; Tue, 8 Jan 2002 14:48:49 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g08JlBW03572; Tue, 8 Jan 2002 13:47:11 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g08JlBr01243; Tue, 8 Jan 2002 13:47:11 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id NAA04819; Tue, 8 Jan 2002 13:47:10 -0600 (CST) Reply-To: To: "'Chiou, Mark'" , "Henry Sinnreich" , , "Robert Sparks" , , , , Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 13:47:09 -0600 Message-ID: <61D824C63B99D311975E00508B0CC98502C66D51@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You are absolutely correct: interworking will exist for quite some time now. If you look over the ISUP interworking draft that Gonzalo, Jon, Lyndon, and I wrote, you'll see that we address this. In fact, we don't solve it; ISUP does -- we just point out the obvious solution. If you'll examine at the way that Q.767 T7 and T11 work, and analyze the implications for SIP interworking, you'll see that the ISUP network, if necessary, will tear down the call, and that PSTN gateways have mechanisms (early-ACM messages) to avert such teardowns. It's all handled on the PSTN side, and needs no provision in the SIP protocol. And that's the way it needs to be. You're always going to have interworking points between networks, and it's their job to provide appropriate "impedance matching" between the networks. We can't take every feature of CAS, ISDN, ISUP, national TUP variants, etc., etc., and add them to SIP in exactly the same way that they work in their native networks. The vagaries of these protocol variations are, by definition, protocol-specific issues. They should be adapted by correctly designed interworking points, not by forcing the round peg of SIP into the variously shaped holes of the myriad PSTN protocols. /a > -----Original Message----- > From: Chiou, Mark [mailto:MChiou@Santera.com] > Sent: Tuesday, January 08, 2002 1:07 PM > To: Henry Sinnreich; adam.roach@ericsson.com; Robert Sparks; > John.Hearty@Level3.com; taylor@nortelnetworks.com; > wtm@research.att.com; > sip@ietf.org > Subject: RE: [Sip] Default value for Timer C (was #282) > > > I agree this is not a PSTN, but don't forget the whole world > is not all > IP yet. > Please think about Cellular networks as an example, there are still a > large portion of the calls interworking with PSTN networks. The same > scenario will be occurred for IP. We CANNOT exclude the > legacy networks > at all. > > A penny worth thought, > > Mark Chiou > Santera _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 16:00:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10337 for ; Tue, 8 Jan 2002 16:00:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA22117 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 16:00:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21579; Tue, 8 Jan 2002 15:42:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21550 for ; Tue, 8 Jan 2002 15:42:22 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09782 for ; Tue, 8 Jan 2002 15:42:21 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g08KUpvw012360; Tue, 8 Jan 2002 15:30:51 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 15:32:35 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E929@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Robert Sparks , "'John.Hearty@Level3.com'" , "'taylor@nortelnetworks.com'" , "'wtm@research.att.com'" , "'sip@ietf.org'" Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 15:32:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org (first version of this got caught in a list administrator trap for length - here's a shorter version. Apologies if both end up getting through) ------ I just realized I had fallen a little too deeply into the minimum value = only deployed value trap. Timer C needs to exist - a proxy element can't be expected to hold state forever, it has to have some point where it knows it can safely discard. If we don't discuss that in the specification, implementations will address it with local policy, potentially to the ruin of interoperation. Elements in real networks will tune this value (the spec should clearly point out that this MUST be configurable). So, a provider could set up a system that would let you work with AA for 45 minutes (or even all day) if they wanted to (at least the proxies wouldn't break the service). Market pressures will eventually drive them providers to use values that enable the applications that people are willing to pay for. So, I have to come back to the very starting point for this thread. Why do we need a minimum value? I think the 3 minutes we've negotiated so far has really been in the spirit of a recommended value, not a minimum. We only need to specify a minimum if use of the protocol with a smaller value will cause really bad things to happen to the network (this is the motivation for the minimum values for T1 yes?). This is different metric than having really bad things happen to applications running on the network. If the value is set to, say 32 seconds, bad things don't happen to the network. There may be some domains of control where its known that calls will complete fast or not at all, and its perfectly reasonable for intermediaries to discard state after 32s. If we make 3 minutes a minimum, we force them to keep state longer than they need it, or be noncompliant, neither of which makes much sense given that they are satisfying the needs of their application. So, I propose that we take what we've learned from the discussion so far and state the following: * Timer C must be configurable * A recommended value for Timer C is 3 minutes * A minimum value for Timer C is ? We haven't really been working to answer that last question - we've been focusing on when applications break, not when the protocol breaks the network. So, is a normative minimum really necessary? If somebody sets Timer C to zero, an INVITE transaction will never complete, which clearly breaks the protocol, so a minimum is needed. If the timer is around the transmission delay, the transaction can complete (though a race condition exists). So, some value larger than the transition delay is necessary. How much bigger? Probably not much. Jonathan's originally suggested 32 seconds. I think it could be much shorter - remember the metric - what breaks the network, not what breaks the applications. I propose the minimum be an RTT. RjS _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 16:30:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10948 for ; Tue, 8 Jan 2002 16:30:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA23126 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 16:30:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22647; Tue, 8 Jan 2002 16:12:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22616 for ; Tue, 8 Jan 2002 16:12:43 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10619 for ; Tue, 8 Jan 2002 16:12:41 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g08LCDF28215; Tue, 8 Jan 2002 13:12:13 -0800 (PST) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABT42196; Tue, 8 Jan 2002 13:12:19 -0800 (PST) From: "Cullen Jennings" To: "Chiou, Mark" Cc: Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Date: Tue, 8 Jan 2002 13:20:34 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Default value to 20 for Max-forwards is way too much. > > Mark Chiou > Santera I don't think that 20 is too much. It is amazing how many proxies one goes through in some deployed systems today. When you start considering ASP's and service route ideas it is going to get even larger than it is today. Cullen _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 16:47:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11418 for ; Tue, 8 Jan 2002 16:47:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24202 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 16:47:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23193; Tue, 8 Jan 2002 16:30:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23146 for ; Tue, 8 Jan 2002 16:30:27 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10951 for ; Tue, 8 Jan 2002 16:30:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08LRqVZ009685; Tue, 8 Jan 2002 16:27:52 -0500 (EST) Message-ID: <3C3B6439.20001@dynamicsoft.com> Date: Tue, 08 Jan 2002 16:27:21 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Sparks CC: "'John.Hearty@Level3.com'" , "'taylor@nortelnetworks.com'" , "'wtm@research.att.com'" , "'sip@ietf.org'" Subject: Re: [Sip] Default value for Timer C (was #282) References: <9BF66EBF6BEFD942915B4D4D45C051F338E929@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > We only need to specify a minimum if use of the protocol with a smaller > value will cause really > bad things to happen to the network (this is the motivation for the > minimum > values for T1 yes?). > This is different metric than having really bad things happen to > applications running on the > network. No, we need to define minimums in order to guarantee interoperability. Relying on "if its wrong, the market pressures will make you crank it up", is not the right answer. That could be applied, in theory, to almost any aspect of the spec (for example, having max-forwards never be greater than three, which means a max of three hops. Its good for the network (less traffic), but bad for apps. I would rather not field these customer support questions. It should work.). Bob has proposed some interesting ways to signal for more time: > 1) Modify the FSMs to restart Timer C for every 1xx response and then > have > the UAS send a 1xx periodically to maintain the transactions in the > proxies. This one is nice, since it has the effect of requring insertion of traffic to refresh state. This helps make it immmune from DoS attacks, which your second proposal below is. > > 2) Include the "expected time" the UAS will take to answer the call in > the > 1xx response and the proxies would set their Timer C accordingly. This > would > still require the UAS to retransmit the 1xx response if the call was not > answered in time, but the proxies would only have to reset the timer > when > they saw the "expected time" value. Well, a malicious UAS could set the value to infinity and blow out the state in proxies. Another approach is the one I had proposed - do nothing. Let the proxies discard state, and I think it still works OK. Any comments on that? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 16:48:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11454 for ; Tue, 8 Jan 2002 16:48:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24245 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 16:48:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23398; Tue, 8 Jan 2002 16:32:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23367 for ; Tue, 8 Jan 2002 16:32:32 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10989 for ; Tue, 8 Jan 2002 16:32:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08LWVVZ009688; Tue, 8 Jan 2002 16:32:31 -0500 (EST) Message-ID: <3C3B654F.6030109@dynamicsoft.com> Date: Tue, 08 Jan 2002 16:31:59 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: sip@ietf.org Subject: Re: [Sip] bis draft: Minor NIT on Supported header Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > The current text in bis-04 10.41 for the Supported header says: > > The Supported general-header field enumerates all the capabilities of > the client or server. This header field SHOULD be included in all > requests (except ACK) and in all responses. > > There would seem to be little point in including this header in a 100 Trying > response, and as I am coming to the conclusion that this is the only header > required to appear apart from the normal mandatory ones, perhaps we should > modify this text slightly to exclude the 100 Trying response. According to bis-05, Supported appears: (a) in any request when the UAC supports extensions, (b) OPTIONS request and 200 response (c) INVITE request and INVITE/200 response I think this is reasoable. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 16:48:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11472 for ; Tue, 8 Jan 2002 16:48:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24264 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 16:48:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23489; Tue, 8 Jan 2002 16:33:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23418 for ; Tue, 8 Jan 2002 16:33:34 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11009; Tue, 8 Jan 2002 16:33:30 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA08506; Tue, 8 Jan 2002 13:32:47 -0800 (PST) Message-ID: <3C3B65A0.A88A474B@cisco.com> Date: Tue, 08 Jan 2002 16:33:21 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3622EB.5040707@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [MMUSIC] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > I've been combing through the sip-implementors and sip lists, looking > for open issues that need resolution, or comments that needed addressing > in the specification. This is the source of much of my spamming on > sip-implementors.... > > An issue that has arisen time and time and time again, is the need for > an endpoint to indicate in its SDP that it can do any one of these three > codecs, but can only do one at a time, that is, it doesn't support > dynamically changing codecs on the fly. Since the question has been > asked 1/2 dozen times on sip-implementors, and concerns both sip and > mmusic, I have cross posted. If the thread takes off we'll trim it to a > single list. > > The response I gave to people who asked about it, was that this was what > simcap > (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.txt) > was for, and to go read that. However, after a discussion with Flemming, > it appears I misinterpreted that specification. It is merely a > declaration of the codes that an endpoint can support. This information > would be used in subsequent offer/answer exchanges, so that a UA can > make an offer without having to guess whether it would or wouldn't be > accepted. I was under the false impression that the point of simcap was > to, in fact, solve this particular problem of one-codec-at-a-time for > the initial exchange. > > So, we are faced with this gap of how to handle this problem. I see a > few solutions: > > 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. > > The offer would list ALL the codecs the UA can do, the counter-offer is > the subset that the other UA can do, and the answer can reduce it > further to just a few. > > This solution would require us to define this 3-way handshake somewhere; > that is still being debated as an open issue. Bill has included this > already in manyfolks, partly to solve this problem (or maybe entirely to > solve this problem). > > 2. Define a backwards compatible usage of simcap to modify the > offer-answer exchange. > > The offer would contain an m line with a single codec choice (in this > particular case where it can do only one a time), but the offer would > include simcap attributes indicating support for other codecs. The > answerer could choose from amongst those codecs in formulating the > answer. So, for example: > > Offer: > > m=audio 8778 RTP/AVP 0 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > > This offer means that the offerer is definitely using PCMU with someone > that doesn't understand simcap, but is indicating they can also do > codecs 1 and 2 (and each of them with rfc2833). The answerer could pick > one of those alternate cdsc in the answer: That's a slight overloading of the simcap semantics which doesn't define any kind of grouping of capabilities. Normal usage of simcap would only list a given capability once (per media stream at least). If you wanted to express something like the above, you would really want to define a new attribute that could describe allowable combinations of codecs, however that level of expressiveness was outside the scope of the simcap specification. > > > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > We would probably need to define an additional attribute in the SDP that > indicates that this "simcap effects the m line selection" semantic is > being followed. > Right. > > This approach may confused intermediaries that are assuming a subset of > codecs in the answer. > > 3. Define a sort-of backwards compatible usage of simcap with offer/answer > > In this model, the offerer lists all codecs they can do in the offer. > They include simcap declarations as well. As with normal offer/answer, > the answerer has to pick a subset, but they use the simcap declarations > to help them pick a subset which is an allowed capability. So, in the > example above where the caller can do codecs 0,2,3,4 along with 76, but > only ONE of 0,2,3,4 at a time, the O/A would look like this: > > OFFER: > > m=audio 8778 RTP/AVP 0 1 2 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > Again, this is a slight overloading of the simcap semantics. > > ANSWER: > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > If, however, the UAS doesn't understand simcap, its possible that > they'll return an SDP listing all four codecs, and possibly change them > on the fly. That can be fixed, in general, by another re-invite which > lists only a single codec. This will work, but might cause an RTT worth > of media to be sent using a codec different from the one the UAC > "loaded" into the DSP. > > 4. Declare that simcap is overkill for this one problem, and define a > single attribute, a=pickone, which says to choose only one of the codecs > in the m line. > > The "I can do one of N, but only one at a time" problem, IMHO, the only > capability problem that anyone actually has in real usage. I will note > that, in fact, this is the only capabilities question ever asked on > sip-implementors. > > A single attribute would easily solve it. If you want to do rfc2833 > along with any one of N other codecs, you could use fid along with this, > to include an m line with the rfc2833, and then another m line with the > N codecs and the a=pickone attribute. > However that would require use of multiple ports which could lead to multiple resource reservations. Also, - fid cannot be added by the answerer if the offer didn't include it due to the media stream matching rules - if fid is included in the offer, but not supported by the answerer, the handling may not be all that graceful. -- Flemming > > One way or another, we need to solve this problem. My apologies for > bringing this up so late, but I had thought it was solved (I thought it > implied approach #3 above).... comments on the various alternatives? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 16:51:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11522 for ; Tue, 8 Jan 2002 16:51:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24336 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 16:51:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23595; Tue, 8 Jan 2002 16:35:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23532 for ; Tue, 8 Jan 2002 16:35:02 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11049; Tue, 8 Jan 2002 16:34:57 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA09398; Tue, 8 Jan 2002 13:34:06 -0800 (PST) Message-ID: <3C3B65EF.21DFD63D@cisco.com> Date: Tue, 08 Jan 2002 16:34:39 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3622EB.5040707@dynamicsoft.com> <3C36312F.F4E4CAAA@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [MMUSIC] Re: [Sip-implementors] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Terry L Anderson wrote: > Jonathan Rosenberg wrote: > > > Folks, > > > > I've been combing through the sip-implementors and sip lists, looking > > for open issues that need resolution, or comments that needed addressing > > in the specification. This is the source of much of my spamming on > > sip-implementors.... > > > > An issue that has arisen time and time and time again, is the need for > > an endpoint to indicate in its SDP that it can do any one of these three > > codecs, but can only do one at a time, that is, it doesn't support > > dynamically changing codecs on the fly. Since the question has been > > asked 1/2 dozen times on sip-implementors, and concerns both sip and > > mmusic, I have cross posted. If the thread takes off we'll trim it to a > > single list. > > > > The response I gave to people who asked about it, was that this was what > > simcap > > (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.txt) > > was for, and to go read that. However, after a discussion with Flemming, > > it appears I misinterpreted that specification. It is merely a > > declaration of the codes that an endpoint can support. This information > > would be used in subsequent offer/answer exchanges, so that a UA can > > make an offer without having to guess whether it would or wouldn't be > > accepted. I was under the false impression that the point of simcap was > > to, in fact, solve this particular problem of one-codec-at-a-time for > > the initial exchange. > > > > So, we are faced with this gap of how to handle this problem. I see a > > few solutions: > > > > 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. > > > > The offer would list ALL the codecs the UA can do, the counter-offer is > > the subset that the other UA can do, and the answer can reduce it > > further to just a few. > > > > This solution would require us to define this 3-way handshake somewhere; > > that is still being debated as an open issue. Bill has included this > > already in manyfolks, partly to solve this problem (or maybe entirely to > > solve this problem). > > > > 2. Define a backwards compatible usage of simcap to modify the > > offer-answer exchange. > > > > The offer would contain an m line with a single codec choice (in this > > particular case where it can do only one a time), but the offer would > > include simcap attributes indicating support for other codecs. The > > answerer could choose from amongst those codecs in formulating the > > answer. So, for example: > > > > Offer: > > > > m=audio 8778 RTP/AVP 0 76 > > a=rtpmap:76 telephone-event > > a=sqn:0 > > a=cdsc: 1 audio RTP/AVP 0 76 > > a=cdsc: 3 audio RTP/AVP 1 76 > > a=cdsc: 5 audio RTP/AVP 2 76 > > > > This offer means that the offerer is definitely using PCMU with someone > > that doesn't understand simcap, but is indicating they can also do > > codecs 1 and 2 (and each of them with rfc2833). The answerer could pick > > one of those alternate cdsc in the answer: > > > > m=audio 7554 RTP/AVP 1 76 > > a=rtpmap:76 telephone-event > > > > We would probably need to define an additional attribute in the SDP that > > indicates that this "simcap effects the m line selection" semantic is > > being followed. > > > > This approach may confused intermediaries that are assuming a subset of > > codecs in the answer. > > > > 3. Define a sort-of backwards compatible usage of simcap with offer/answer > > > > In this model, the offerer lists all codecs they can do in the offer. > > They include simcap declarations as well. As with normal offer/answer, > > the answerer has to pick a subset, but they use the simcap declarations > > to help them pick a subset which is an allowed capability. So, in the > > example above where the caller can do codecs 0,2,3,4 along with 76, but > > only ONE of 0,2,3,4 at a time, the O/A would look like this: > > > > OFFER: > > > > m=audio 8778 RTP/AVP 0 1 2 76 > > a=rtpmap:76 telephone-event > > a=sqn:0 > > a=cdsc: 1 audio RTP/AVP 0 76 > > a=cdsc: 3 audio RTP/AVP 1 76 > > a=cdsc: 5 audio RTP/AVP 2 76 > > > > ANSWER: > > m=audio 7554 RTP/AVP 1 76 > > a=rtpmap:76 telephone-event > > > > If, however, the UAS doesn't understand simcap, its possible that > > they'll return an SDP listing all four codecs, and possibly change them > > on the fly. That can be fixed, in general, by another re-invite which > > lists only a single codec. This will work, but might cause an RTT worth > > of media to be sent using a codec different from the one the UAC > > "loaded" into the DSP. > > > > 4. Declare that simcap is overkill for this one problem, and define a > > single attribute, a=pickone, which says to choose only one of the codecs > > in the m line. > > > > The "I can do one of N, but only one at a time" problem, IMHO, the only > > capability problem that anyone actually has in real usage. I will note > > that, in fact, this is the only capabilities question ever asked on > > sip-implementors. > > > > A single attribute would easily solve it. If you want to do rfc2833 > > along with any one of N other codecs, you could use fid along with this, > > to include an m line with the rfc2833, and then another m line with the > > N codecs and the a=pickone attribute. > > simcap is indeed overkill for this and I like new attribute as long as we relax > the requirement currently in offer-answer: > "Once the offerer has sent the offer, it MUST be prepared to receive > media described by that offer." > That would be a radical change from present-day SDP semantics. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 16:55:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11607 for ; Tue, 8 Jan 2002 16:55:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24454 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 16:55:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23730; Tue, 8 Jan 2002 16:39:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23703 for ; Tue, 8 Jan 2002 16:39:41 -0500 (EST) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11229 for ; Tue, 8 Jan 2002 16:39:40 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Tue, 8 Jan 2002 15:39:08 -0600 Message-ID: Thread-Topic: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Thread-Index: AcGYiTgyajIm+QGrTZiKx2dTQrSTLgAAZi9w From: "Chiou, Mark" To: "Cullen Jennings" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA23704 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I see your point, but I thought the internet is no boundary such that the hops should be less than the SS7 networks. For example, a call for Dallas US to Beijing China, The call might only needs one national gateway in Dallas, one international gateway in Seattle US, one in Japan to tandem to China for PSTN network. This is the best scenario of course, it requires 5 to 6 switches. For IP world, If the IP address can be resulted to China directly, then only 2 to 3 Proxies are needed. Am I missing something? Plus, do we consider the performance for two many hops? Mark Chiou -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Tuesday, January 08, 2002 3:21 PM To: Chiou, Mark Cc: sip@ietf.org Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers > Default value to 20 for Max-forwards is way too much. > > Mark Chiou > Santera I don't think that 20 is too much. It is amazing how many proxies one goes through in some deployed systems today. When you start considering ASP's and service route ideas it is going to get even larger than it is today. Cullen _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 16:58:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11672 for ; Tue, 8 Jan 2002 16:58:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24501 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 16:58:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23919; Tue, 8 Jan 2002 16:41:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23776 for ; Tue, 8 Jan 2002 16:41:15 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11281; Tue, 8 Jan 2002 16:41:13 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA13486; Tue, 8 Jan 2002 13:40:21 -0800 (PST) Message-ID: <3C3B6763.AF18D06B@cisco.com> Date: Tue, 08 Jan 2002 16:40:52 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jerry_yin@Mitel.COM CC: "'Jonathan Rosenberg'" , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <000401c1957a$72fce690$0c4dc786@pc3002.mitel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [MMUSIC] RE: [Sip-implementors] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jerry Yin wrote: > Hi there, > > After I read the simcap > (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx > t), I found that it is not backwards compatible with the SDP (RFC 2327). > Here's my comments. > > 1. the rtpmap's format in RFC 2327 is > > a=rtpmap: /[/ parameters>]. > While in simcap, it is : > a=rtpmap: telephone-event No. There's simply an example which has made an editorial mistake in omitting the . > > > Where is the "telephone-event" defined as an encoding name? RFC 2833. > If the UA is > implemented according to RFC 2327, how can it talk to the UAs implemented > according to the simcap? > Per RFC 2327, unknown attributes are simply ignored and simcap just defines a couple of extra attributes that can be ignored at will. > > 2. The "m=" header and "a=rtpmap" in RFC 2327 is good enough to describe the > media attributes already. I don't know why it is necessary to define a new > attributes of "a=cdsc" and "a=cpar". There are some redundant information > here, I think. > SDP has well-known shortcomings when it comes to capability description and negotiation. See e.g. http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-req-01.txt for an analysis of these. > > 3. If we want to describe a subset of capabilities among all capabilities > the SDP claimed, we can simply introduce one new attribute to describe the > subset. > For example, > a=subset subset_codec_number : total_codec_number. > This way, even some UAs don't understand a = subset, they still can talk > with the one supports this attribute by at list one media streaming. > They can, but not with the semantics you intended. > > Here's an example: > v=0 > o=- 25678 753849 IN IP4 128.96.41.1 > s=- > c=IN IP4 128.96.41.1 > t=0 0 > m=audio 3456 RTP/AVP 96 97 98 > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > a=rtpmap:98 L16/11025/2 > a=subset 2:3 > m=video 3458 RTP/AVP 26 31 > a=rtpmap:26 JPEG/90000 > a=rtpmap:31 H261/90000 > a=subset 1:2 > > This packet means the sender can support two audio streams among three > different codecs {L8, L16, and L16-stereo} and one video stream of JPEG or > H261. This doesn't work if the receiver doesn't understand the "subset" attribute, hence it's not backwards compatible. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 17:13:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11990 for ; Tue, 8 Jan 2002 17:13:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25610 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 17:13:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24319; Tue, 8 Jan 2002 16:50:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24288 for ; Tue, 8 Jan 2002 16:50:21 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11515 for ; Tue, 8 Jan 2002 16:50:19 -0500 (EST) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g08LlCW16328; Tue, 8 Jan 2002 15:47:12 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g08LlCx07414; Tue, 8 Jan 2002 15:47:12 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id PAA16517; Tue, 8 Jan 2002 15:47:11 -0600 (CST) Reply-To: To: "'Jonathan Rosenberg'" , "Robert Sparks" Cc: , , , Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 15:47:09 -0600 Message-ID: <61D824C63B99D311975E00508B0CC98502C66D54@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <3C3B6439.20001@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Bob has proposed some interesting ways to signal for more time: > > > 1) Modify the FSMs to restart Timer C for every 1xx > response and then > > have > > the UAS send a 1xx periodically to maintain the transactions in the > > proxies. > > This one is nice, since it has the effect of requiring insertion of > traffic to refresh state. This helps make it immune from DoS > attacks > ... > Another approach is the one I had proposed - do nothing. Let > the proxies > discard state, and I think it still works OK. Any comments on that? Yes. I'd like to avoid this approach, in part because it makes firewalling far too difficult. I like ignoring the firewall issue as much as the next guy, but it seems like the Bob's solution (1), above, is much cleaner -- and it helps with the firewall case as well. /a _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 17:18:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12082 for ; Tue, 8 Jan 2002 17:18:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25696 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 17:18:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24555; Tue, 8 Jan 2002 16:59:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24524 for ; Tue, 8 Jan 2002 16:59:17 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11700 for ; Tue, 8 Jan 2002 16:59:15 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id VAA03575; Tue, 8 Jan 2002 21:53:35 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id VAA19393; Tue, 8 Jan 2002 21:59:17 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jan 2002 14:59:12 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B37117@n0214idc1.oss.level3.com> To: jdrosen@dynamicsoft.com, rsparks@dynamicsoft.com Cc: taylor@nortelnetworks.com, wtm@research.att.com, sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 14:59:17 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Comments inline. Note that this is not one of the major issues, but has been getting alot of attention. We should try to choose a solution quickly. My vote is below. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, January 08, 2002 2:27 PM > To: Robert Sparks > Cc: Hearty, John; 'taylor@nortelnetworks.com'; 'wtm@research.att.com'; > 'sip@ietf.org' > Subject: Re: [Sip] Default value for Timer C (was #282) > > > > > Robert Sparks wrote: > > > > > > We only need to specify a minimum if use of the protocol > with a smaller > > value will cause really > > bad things to happen to the network (this is the motivation for the > > minimum > > values for T1 yes?). > > This is different metric than having really bad things happen to > > applications running on the > > network. > > > No, we need to define minimums in order to guarantee > interoperability. > Relying on "if its wrong, the market pressures will make you crank it > up", is not the right answer. That could be applied, in theory, to > almost any aspect of the spec (for example, having > max-forwards never be > greater than three, which means a max of three hops. Its good for the > network (less traffic), but bad for apps. I would rather not > field these > customer support questions. It should work.). > > Bob has proposed some interesting ways to signal for more time: > > > > 1) Modify the FSMs to restart Timer C for every 1xx > response and then > > have > > the UAS send a 1xx periodically to maintain the transactions in the > > proxies. > > > This one is nice, since it has the effect of requring insertion of > traffic to refresh state. This helps make it immmune from DoS > attacks, > which your second proposal below is. > This solution currently gets my vote (is this a democracy?). The problems prompting some to want the timer to be long would be solved by the user that needs it to be long, the UAS. The minimum could then be some small value such as 32s as originally proposed. > > > > > 2) Include the "expected time" the UAS will take to answer > the call in > > the > > 1xx response and the proxies would set their Timer C > accordingly. This > > would > > still require the UAS to retransmit the 1xx response if the > call was not > > answered in time, but the proxies would only have to reset the timer > > when > > they saw the "expected time" value. > > > Well, a malicious UAS could set the value to infinity and > blow out the > state in proxies. > > Another approach is the one I had proposed - do nothing. Let > the proxies > discard state, and I think it still works OK. Any comments on that? I was hoping Robert Sparks would comment on what you discussed ealier today, the points sounded interesting. If the stateless forwarding of responses and Routing of ACKs would hold the call up, I'm not clear why Robert and Henry are having their calls dropped after a minute, unless it's really a PSTN switch they are ultimately interworking with that is dropping the call. If the points made are ultimately valid, then this approach would seem the best and my vote would change to this, as it would remove a requirement of UAS's to retransmit provisionals and proxies to reset timers. Again, a minimum would still need to be chosen here such as the originally proposed 32s. John Hearty Level3 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 17:29:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12401 for ; Tue, 8 Jan 2002 17:28:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25921 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 17:28:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25406; Tue, 8 Jan 2002 17:09:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25375 for ; Tue, 8 Jan 2002 17:09:41 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11912 for ; Tue, 8 Jan 2002 17:09:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g08M9YVZ009715; Tue, 8 Jan 2002 17:09:35 -0500 (EST) Message-ID: <3C3B6DFF.4090506@dynamicsoft.com> Date: Tue, 08 Jan 2002 17:09:03 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: sip@ietf.org Subject: Re: [Sip] Priority header Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >>>The bis draft says it is optional to include only in the >>>INVITE request. >>>The manyfolks draft says it is optional to include in the >>>COMET request. >>>RFC 2976 says it is optional to include in the INFO request. >>>The refer draft says that it is not included in a REFER request. >>> >>>I assume that there is some ISUP mapping reason why it is >>>included in an >>>INFO, presumably because the information came later than when >>>the INVITE was >>>sent - is this true? If untrue, then it should not be in INFO. >>> >>Priority is one of these mostly harmless headers. If it doesn't make sense >>in a method, its inclusion doesn't hurt anything. >> >> > This would be a justification if Priority had been included in all and > everything, but Priority appears to be one of those headers where the usage > is directed to where it is useful. In the bis draft it is only included in > INVITE. Good point indeed. I have logged a bug to include additional text to clarify the semantics of Priority better, since there generally has been confusion about it. The text will also say that the header is really only useful in requests that have some user provided policy as input to determine the response. After all, the point of priority is for UI or policy processing. As such, I do think it is a mistake to include it in COMET. It might be useful in INFO depending on what its being used for. bis now specifies that it is not included in PRACK. Arguably, it might make sense in REFER "you really got to call this guy NOW", since there is policy in processing refer. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 17:45:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12776 for ; Tue, 8 Jan 2002 17:45:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26651 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 17:45:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25869; Tue, 8 Jan 2002 17:25:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25845 for ; Tue, 8 Jan 2002 17:25:30 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12330 for ; Tue, 8 Jan 2002 17:25:28 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA13837; Tue, 8 Jan 2002 17:25:25 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g08MPEJ1000168; Tue, 8 Jan 2002 17:25:19 -0500 (EST) Message-ID: <3C3B71CA.D30DDA7A@cs.columbia.edu> Date: Tue, 08 Jan 2002 17:25:14 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Drage, Keith (Keith)" , sip@ietf.org Subject: Re: [Sip] Priority header References: <3C3B6DFF.4090506@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Good point indeed. > > I have logged a bug to include additional text to clarify the semantics > of Priority better, since there generally has been confusion about it. > The text will also say that the header is really only useful in requests > that have some user provided policy as input to determine the response. > After all, the point of priority is for UI or policy processing. Yes, and a source of confusion that the wording in the Resource-Priority draft tried to address. > > As such, I do think it is a mistake to include it in COMET. It might be > useful in INFO depending on what its being used for. bis now specifies > that it is not included in PRACK. Arguably, it might make sense in REFER > "you really got to call this guy NOW", since there is policy in > processing refer. And MESSAGE, SUBSCRIBE, etc. - anytime a user choice is likely. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 18:03:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13228 for ; Tue, 8 Jan 2002 18:03:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA27256 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 18:01:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26402; Tue, 8 Jan 2002 17:34:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26371 for ; Tue, 8 Jan 2002 17:34:12 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12502 for ; Tue, 8 Jan 2002 17:34:10 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g08MVKvw013394; Tue, 8 Jan 2002 17:31:20 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Jan 2002 17:33:04 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E92A@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'John.Hearty@Level3.com'" , Jonathan Rosenberg , Robert Sparks Cc: taylor@nortelnetworks.com, wtm@research.att.com, sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 17:33:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] > Sent: Tuesday, January 08, 2002 3:59 PM > To: jdrosen@dynamicsoft.com; rsparks@dynamicsoft.com > Cc: taylor@nortelnetworks.com; wtm@research.att.com; sip@ietf.org > Subject: RE: [Sip] Default value for Timer C (was #282) > > > Comments inline. Note that this is not one of the major > issues, but has > been getting alot of attention. We should try to choose a > solution quickly. > My vote is below. > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, January 08, 2002 2:27 PM > > To: Robert Sparks > > Cc: Hearty, John; 'taylor@nortelnetworks.com'; > 'wtm@research.att.com'; > > 'sip@ietf.org' > > Subject: Re: [Sip] Default value for Timer C (was #282) > > > > > > > > > > Robert Sparks wrote: > > > > > > > > > > We only need to specify a minimum if use of the protocol > > with a smaller > > > value will cause really > > > bad things to happen to the network (this is the > motivation for the > > > minimum > > > values for T1 yes?). > > > This is different metric than having really bad things happen to > > > applications running on the > > > network. > > > > > > No, we need to define minimums in order to guarantee > > interoperability. Interoperability of what? If I want a _mimimum_ to _guarantee_ interoperability with the PSTN (the way AA uses it), I need a minimum that is much higher than we collectively think is sane. > > Relying on "if its wrong, the market pressures will make > you crank it > > up", is not the right answer. > > I think you are caught in the same minimum=recommended= manditorily deployed value misconception I was caught in. This value is one that will need to be tuned (although the importance of tuning goes way down if we can cause timer C to restart through provisional responses) and the market is exactly what will tune it up or down. The only point in having a minimum is keeping them from tuning it down so far it causes the protocol itself to break or become a menace to its environment. > > That could be applied, in theory, to > > almost any aspect of the spec (for example, having > > max-forwards never be > > greater than three, which means a max of three hops. Its > good for the > > network (less traffic), but bad for apps. I would rather not > > field these > > customer support questions. It should work.). So a recommended initial value of max forwards is probably wrong. For most people, it will be insufficient. For some, it will be just fine. Are you going to specify a minimum, making me violate spec to insert a header with a Max-Forwards of 1? I may really be into avoiding proxies someday. Further, whatever _recommended_ value you choose is, again, going to have to be tunable (the 5G folks will come in with a system that mandates 11 hops per carrier, so intercarrier INVITES will have to transit at least 22). > > > > Bob has proposed some interesting ways to signal for more time: > > > > > > > 1) Modify the FSMs to restart Timer C for every 1xx > > response and then > > > have > > > the UAS send a 1xx periodically to maintain the > transactions in the > > > proxies. > > > > > > This one is nice, since it has the effect of requring insertion of > > traffic to refresh state. This helps make it immmune from DoS > > attacks, > > which your second proposal below is. > > > > This solution currently gets my vote (is this a democracy?). > The problems > prompting some to want the timer to be long would be solved > by the user that > needs it to be long, the UAS. The minimum could then be some > small value > such as 32s as originally proposed. > > > > > > > > > 2) Include the "expected time" the UAS will take to answer > > the call in > > > the > > > 1xx response and the proxies would set their Timer C > > accordingly. This > > > would > > > still require the UAS to retransmit the 1xx response if the > > call was not > > > answered in time, but the proxies would only have to > reset the timer > > > when > > > they saw the "expected time" value. > > > > > > Well, a malicious UAS could set the value to infinity and > > blow out the > > state in proxies. > > > > Another approach is the one I had proposed - do nothing. Let > > the proxies > > discard state, and I think it still works OK. Any comments on that? > > > I was hoping Robert Sparks would comment on what you > discussed ealier today, > the points sounded interesting. As adam pointed out, this doesn't survive proxies that are controlling access through firewalls. > > > If the stateless forwarding > of responses > and Routing of ACKs would hold the call up, I'm not clear why > Robert and > Henry are having their calls dropped after a minute, unless > it's really a > PSTN switch they are ultimately interworking with that is > dropping the call. The calls are dropping today because of implementations that don't allow control over providing an expires header with a long value. This discussion of timer C combined with proxies ignoring expires was introducing a new place where the protocol would tank the call if implemented. > If the points made are ultimately valid, then this approach > would seem the > best and my vote would change to this, as it would remove a > requirement of > UAS's to retransmit provisionals and proxies to reset timers. > Again, a > minimum would still need to be chosen here such as the > originally proposed > 32s. > > > John Hearty > Level3 > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 18:10:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13382 for ; Tue, 8 Jan 2002 18:10:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA27527 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 18:10:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26638; Tue, 8 Jan 2002 17:45:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26607 for ; Tue, 8 Jan 2002 17:45:24 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12766 for ; Tue, 8 Jan 2002 17:45:21 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA08767; Tue, 8 Jan 2002 14:44:45 -0800 (PST) Message-Id: <4.1.20020108163511.0128aae0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 Jan 2002 16:44:27 -0600 To: Jonathan Rosenberg , "Drage, Keith (Keith)" From: "James M. Polk" Subject: Re: [Sip] Priority header Cc: sip@ietf.org In-Reply-To: <3C3B6DFF.4090506@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1912631578==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_1912631578==_.ALT Content-Type: text/plain; charset="us-ascii" At 05:09 PM 1/8/2002 -0500, Jonathan Rosenberg wrote: > > > >>>>The bis draft says it is optional to include only in the >>>>INVITE request. >>>>The manyfolks draft says it is optional to include in the >>>>COMET request. >>>>RFC 2976 says it is optional to include in the INFO request. >>>>The refer draft says that it is not included in a REFER request. >>>> >>>>I assume that there is some ISUP mapping reason why it is >>>>included in an >>>>INFO, presumably because the information came later than when >>>>the INVITE was >>>>sent - is this true? If untrue, then it should not be in INFO. >>>> >>>Priority is one of these mostly harmless headers. If it doesn't make sense >>>in a method, its inclusion doesn't hurt anything. >>> >>> >> This would be a justification if Priority had been included in all and >> everything, but Priority appears to be one of those headers where the usage >> is directed to where it is useful. In the bis draft it is only included in >> INVITE. > > >Good point indeed. > >I have logged a bug to include additional text to clarify the semantics >of Priority better, since there generally has been confusion about it. >The text will also say that the header is really only useful in requests >that have some user provided policy as input to determine the response. >After all, the point of priority is for UI or policy processing. Thank you -- clarification is needed in the .bis text, but it doesn't require much IMO > >As such, I do think it is a mistake to include it in COMET. It might be >useful in INFO depending on what its being used for. bis now specifies >that it is not included in PRACK. Arguably, it might make sense in REFER >"you really got to call this guy NOW", since there is policy in >processing refer. This makes sense in the case of REFER. > >-Jonathan R. > > > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PH: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1912631578==_.ALT Content-Type: text/html; charset="us-ascii"
At 05:09 PM 1/8/2002 -0500, Jonathan Rosenberg wrote:
>
>
>
>>>>The bis draft says it is optional to include only in the
>>>>INVITE request.
>>>>The manyfolks draft says it is optional to include in the
>>>>COMET request.
>>>>RFC 2976 says it is optional to include in the INFO request.
>>>>The refer draft says that it is not included in a REFER request.
>>>>
>>>>I assume that there is some ISUP mapping reason why it is
>>>>included in an
>>>>INFO, presumably because the information came later than when
>>>>the INVITE was
>>>>sent - is this true? If untrue, then it should not be in INFO.
>>>>
>>>Priority is one of these mostly harmless headers. If it doesn't make sense
>>>in a method, its inclusion doesn't hurt anything.
>>>
>>>
>> This would be a justification if Priority had been included in all and
>> everything, but Priority appears to be one of those headers where the usage
>> is directed to where it is useful. In the bis draft it is only included in
>> INVITE.
>
>
>Good point indeed.
>
>I have logged a bug to include additional text to clarify the semantics
>of Priority better, since there generally has been confusion about it.
>The text will also say that the header is really only useful in requests
>that have some user provided policy as input to determine the response.
>After all, the point of priority is for UI or policy processing.

Thank you -- clarification is needed in the .bis text, but it doesn't require much IMO

>
>As such, I do think it is a mistake to include it in COMET. It might be
>useful in INFO depending on what its being used for. bis now specifies
>that it is not included in PRACK. Arguably, it might make sense in REFER
>"you really got to call this guy NOW", since there is policy in
>processing refer.

This makes sense in the case of REFER.

>
>-Jonathan R.
>
>
>
>--
>Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
>Chief Scientist                         First Floor
>dynamicsoft                             East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
>http://www.jdrosen.net                  PH:  (973) 952-5000
>
>
>_______________________________________________
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1912631578==_.ALT-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 18:44:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14158 for ; Tue, 8 Jan 2002 18:44:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28469 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 18:44:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27726; Tue, 8 Jan 2002 18:24:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27695 for ; Tue, 8 Jan 2002 18:24:21 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13698 for ; Tue, 8 Jan 2002 18:24:19 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id AFA2ECF80150; Tue, 08 Jan 2002 18:24:18 -0500 Message-ID: <004701c1989a$fdedf320$2300000a@acmepacket.com> From: "Bob Penfield" To: "Jonathan Rosenberg" , "Robert Sparks" Cc: "'John.Hearty@Level3.com'" , , , References: <9BF66EBF6BEFD942915B4D4D45C051F338E929@DYN-TX-EXCH-001.dynamicsoft.com> <3C3B6439.20001@dynamicsoft.com> Subject: Re: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 18:19:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jonathan Rosenberg" > Another approach is the one I had proposed - do nothing. Let the proxies > discard state, and I think it still works OK. Any comments on that? > Maybe I am missing something, but my reading of Section 16 requires that a stateful proxy send a final response when all of the client transactions have been terminated. This would result in a non-2xx final response being sent to the UAC (namely 408). Lines 2351-2357: A stateful proxy MUST send a final response to a response context's server transaction if no final responses have been immediately forwarded by the above rules and all client transactions in this response context have been terminated. The stateful proxy MUST choose the "best" final response among those received and stored in the response context. If there are no final responses in the context, the proxy MUST send a 408 (Request Timeout) response to the server transaction. If this is correct, there needs to be a way to retain the state in the proxy. cheers, (-:bob _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 18:44:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14176 for ; Tue, 8 Jan 2002 18:44:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28483 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 18:44:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27772; Tue, 8 Jan 2002 18:25:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27742 for ; Tue, 8 Jan 2002 18:25:02 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13714 for ; Tue, 8 Jan 2002 18:25:00 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id AFCCEDE40150; Tue, 08 Jan 2002 18:25:00 -0500 Message-ID: <004f01c1989b$16d69900$2300000a@acmepacket.com> From: "Bob Penfield" To: "Robert Sparks" , "'John.Hearty@Level3.com'" , "Jonathan Rosenberg" Cc: , , References: <9BF66EBF6BEFD942915B4D4D45C051F338E92A@DYN-TX-EXCH-001.dynamicsoft.com> Subject: Re: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 18:20:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Robert Sparks" > The calls are dropping today because of implementations that don't > allow control over providing an expires header with a long value. > This discussion of timer C combined with proxies ignoring expires > was introducing a new place where the protocol would tank the call if > implemented. Even if this was allowed, how does the calling UA know how the far end behaves? The called UA knows, so it could do something about it. cheers, (-:bob _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 22:11:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17806 for ; Tue, 8 Jan 2002 22:11:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA04323 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 22:11:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03550; Tue, 8 Jan 2002 21:50:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03509 for ; Tue, 8 Jan 2002 21:50:54 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17537 for ; Tue, 8 Jan 2002 21:50:51 -0500 (EST) Received: from jku.dynamicsoft.com (dhcp242.fokus.gmd.de [195.37.78.242]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g092nUY15023; Wed, 9 Jan 2002 03:49:31 +0100 Message-Id: <5.1.0.14.0.20020109035041.00a78f40@mailhost.fokus.gmd.de> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Jan 2002 03:50:45 +0100 To: "Bob Penfield" , "Jonathan Rosenberg" , "Robert Sparks" From: Jiri Kuthan Subject: Re: [Sip] Default value for Timer C (was #282) Cc: "'John.Hearty@Level3.com'" , , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 12:19 AM 1/9/2002, Bob Penfield wrote: >----- Original Message ----- >From: "Jonathan Rosenberg" > >> Another approach is the one I had proposed - do nothing. Let the proxies >> discard state, and I think it still works OK. Any comments on that? >> > >Maybe I am missing something, but my reading of Section 16 requires that a >stateful proxy send a final response when all of the client transactions >have been terminated. This would result in a non-2xx final response being >sent to the UAC (namely 408). > >If this is correct, there needs to be a way to retain the state in the >proxy. I read it the same way but do not see how changing it will harm interoperability. There are other protols which were designed for state storage and do that job better than SIP does. -Jiri _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 22:11:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17820 for ; Tue, 8 Jan 2002 22:11:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA04337 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 22:12:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03573; Tue, 8 Jan 2002 21:51:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03515 for ; Tue, 8 Jan 2002 21:50:55 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17539 for ; Tue, 8 Jan 2002 21:50:52 -0500 (EST) Received: from jku.dynamicsoft.com (dhcp242.fokus.gmd.de [195.37.78.242]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g092nSY15017; Wed, 9 Jan 2002 03:49:29 +0100 Message-Id: <5.1.0.14.0.20020109032831.02982580@mailhost.fokus.gmd.de> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Jan 2002 03:43:32 +0100 To: Jonathan Rosenberg , Robert Sparks From: Jiri Kuthan Subject: Re: [Sip] Default value for Timer C (was #282) Cc: "'John.Hearty@Level3.com'" , taylor@nortelnetworks.com, wtm@research.att.com, sip@ietf.org In-Reply-To: <3C3B2577.7070002@dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F338E926@DYN-TX-EXCH-001.dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org >Actually, its not clear to me that things won't work with timer C at 3m. Lets say you've called AA, and after 3m, the proxies give up. Let us say that the DONT CANCEL, but just discard all state. The terminating GW doesnt' give up, since it knows there is media in progress. Same with your calling UAC. Now, after 30m, the call is answered. A 200 OK is sent by the terminating GW. This 200 OK will be properly routed back to the UAC even without transaction state in any proxies. The ACK will be routed based on the route set, and should get there as well. > >If the call is rejected, a 4xx will be sent by the terminating GW. The previous hop proxy will statelessly forward it as well, and the behavior will effectively look like the 2xx/ACK case, with the 4xx being retransmitted by UAS, and the ACK by the UAC. The ACK for the non-2xx case won't have route headers, so it may or may not get delivered to the terminating gateway, but the odds are actually good. > >This is a fine example of the benefits of stateless operation. > >Things will break in the case of a forking proxy. If timer C expires and it doesn't cancel, the UAC may end up getting multiple non-2xx responses. There are a few possible solutions to this one: > > a. the proxy cancels all but one branch (the one that returned the 1xx), and then drops its state. This allows that one branch to continue > b. so what if the uac gets multiple non-2xx. It accepts the first, drops the rest. ad b) Note that quite interesting call flows may happen. Proxy forks a reqeust from A to X and Z. Both reply with 183 (interesting media issue for A). Timer C hits the proxy which goes stateless silently. X establishes the call using the stateless proxy. The call is BYE-ed, it no more exists. Z sends a final response. No ACK comes from A so Z keeps retransmitting its final response for some time. More detailed arguing follows separately. The major point is C can be very low too and silent transaction dropping for non-forking is good. With forking, it may take longer C and explicit cancellation. -Jiri _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 8 22:14:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17940 for ; Tue, 8 Jan 2002 22:14:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA04366 for sip-archive@odin.ietf.org; Tue, 8 Jan 2002 22:14:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03490; Tue, 8 Jan 2002 21:50:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03386 for ; Tue, 8 Jan 2002 21:50:13 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17532 for ; Tue, 8 Jan 2002 21:50:10 -0500 (EST) Received: from jku.dynamicsoft.com (dhcp242.fokus.gmd.de [195.37.78.242]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g092nUY15020 for ; Wed, 9 Jan 2002 03:49:30 +0100 Message-Id: <5.1.0.14.0.20020109034339.026c0b38@mailhost.fokus.gmd.de> X-Sender: jiri@iptel.org X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Jan 2002 03:44:08 +0100 To: sip@ietf.org From: Jiri Kuthan Subject: Re: [Sip] Default value for Timer C (was #282) In-Reply-To: <3C3B2577.7070002@dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F338E926@DYN-TX-EXCH-001.dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Summary: C-timer required to be as huge as 3 minutes eats proxy memory badly while providing questionnable benefits -> please, don't do that and allow C to be small for economical proxies; real size of C and handling of C timer can vary depending on functionality. I think it can be quite low (4sec?). Sometimes, it must be longer to meet user expectations (forking ... 32 sec). Special cases (forking to multiple AA "183 next agent will serve you" destinations) may ask for even longer C. C in phones can even be infinite. C may be in hands of users too (CPL: forward-on-busy with user-driven timeout). -Jiri -------- In order to be robust, I really want to remove transaction context asap. This has been nicely hard-wired in protocol and proxy "randez-vous" concept from SIP's beginning. Who doesn't agree and wants to make a storage server out of a proxy may try putting it under heavy load. You'll see that running out of memory will happen *very* soon (unless you have terrabytes of fast memory and kilobits of bandwidth). Making a proxy call-stateful by keeping state during 5-minutes-long 183 replies is simply too heavy. From this point of view, I would recommend against REQUIRING C to be long (long: > 32 sec). I think it can be frequently very short (like 4 sec) without any harm. Specifically, if the use of state in proxy is retransmission (good if for example upstream client is on a wireless link and I want the proxy to deal with retransmissions on its behalf). Then, - short C timer hurts neither for 2xx (2xx are always relayed even by stateful proxies) nor for 3xx-6xx which are mostly automated and come back very quickly - and if C hits (like with loooong 183), the proxy may discard transaction state silently (no CANCEL, no 408) -- upstream and downstream willing to wait for each other will finish the transaction with stateless proxy; the great thing is there is no evil intermediary proxy stopping parties from waiting for each other too early It's trickier, if the purpose of state is different (i.e., if the proxy does more than cleaning transaction state when C timer hits or a final response comes). All kinds of forking are a terrifying example. Because we do not want to put the forking burden on upstream client unexpectedly, the proxy cannot release transaction context silently (->CANCEL, 408). And because we do not want to hurt users by early cancellation, C cannot be too low. 32 sec would be perhaps enough. Dedicated waiters may push the redial button. That's still quite nice, however troubles multiply in special case of forking to multiple 1xx destinations. What do you do after C hits (be it 3 minutes), two AA agents keep feeding you with early media and you are still ready to wait for a human representative? (I mean from signaling perspective. I am open to discussion of mixing early media, though ;-) Cancelling is unhappy in this case -- the caller is still willing to wait. Silent state releasing is not possible because that would put forking burden upstream. I argue forking to multiple destinations which will return 1xx for long time and caller will keep waiting is a special case. So special that whoever configures the proxy to do so will be aware of how special it is, rise C and buy enough RAM. Implementers of call distribution by forking might do so, for (PSTN-free) example. Implementors of standard proxies might cancel all but one branch before going stateless if they fear 32 sec is not good enough. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 00:23:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20620 for ; Wed, 9 Jan 2002 00:23:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA08019 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 00:23:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07374; Wed, 9 Jan 2002 00:02:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07346 for ; Wed, 9 Jan 2002 00:02:26 -0500 (EST) Received: from esuims01.esamsungumit.com ([203.122.29.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20400 for ; Wed, 9 Jan 2002 00:02:22 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Wed, 9 Jan 2002 10:37:01 +0530 Message-ID: <89CFEE6120A0224EA07781892EC0B48B43C3B4@esuims01.esamsungumit.com> Thread-Topic: [Sip] Default value for Timer C (was #282) Thread-Index: AcGYvGy7v6OwjLakRIG5OVSy1GKKUAADshJA From: "ShavinderPal Singh" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA07347 Subject: [Sip] Post Dial Delay Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Can any one tell me which rfc caters to the "definition" of "Post Dial delay" in SIP. and how to calculate it? If there is none, can anyone help me how do i verify if my Post Dial delay is less than 1.5 RTT Rgds s eSamsung UMIT, 15th floor, Signature Towers, South City-I, Gurgaon-122001, HR, IND. Ph.: 091-124-6383474 (e 250) _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 00:30:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20855 for ; Wed, 9 Jan 2002 00:30:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA08479 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 00:30:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07756; Wed, 9 Jan 2002 00:11:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07688 for ; Wed, 9 Jan 2002 00:11:32 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20503; Wed, 9 Jan 2002 00:11:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g095B3VZ010681; Wed, 9 Jan 2002 00:11:04 -0500 (EST) Message-ID: <3C3BD0C5.4030301@dynamicsoft.com> Date: Wed, 09 Jan 2002 00:10:29 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Flemming Andreasen CC: sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3B65A0.A88A474B@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [MMUSIC] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > >>Offer: >> >>m=audio 8778 RTP/AVP 0 76 >>a=rtpmap:76 telephone-event >>a=sqn:0 >>a=cdsc: 1 audio RTP/AVP 0 76 >>a=cdsc: 3 audio RTP/AVP 1 76 >>a=cdsc: 5 audio RTP/AVP 2 76 >> >>This offer means that the offerer is definitely using PCMU with >> > someone > >>that doesn't understand simcap, but is indicating they can also do >>codecs 1 and 2 (and each of them with rfc2833). The answerer could >> > pick > >>one of those alternate cdsc in the answer: >> > > That's a slight overloading of the simcap semantics which doesn't define > any kind > of grouping of capabilities. Normal usage of simcap would only list a > given > capability once (per media stream at least). If you wanted to express > something > like the above, you would really want to define a new attribute that > could > describe allowable combinations of codecs, however that level of > expressiveness > was outside the scope of the simcap specification. I understand that now as well, once again, my misinterpretation of the simcap spec. Clearly I thought it was solving something that it is not. This leaves a larger hole than I thought. >>4. Declare that simcap is overkill for this one problem, and define a >>single attribute, a=pickone, which says to choose only one of the >>codecs in the m line. >>The "I can do one of N, but only one at a time" problem, IMHO, the >>only >>capability problem that anyone actually has in real usage. I will note >>that, in fact, this is the only capabilities question ever asked on >>sip-implementors. >> >>A single attribute would easily solve it. If you want to do rfc2833 >>along with any one of N other codecs, you could use fid along with >>this, to include an m line with the rfc2833, and then another m line with >>the N codecs and the a=pickone attribute. >> >> > > However that would require use of multiple ports which could lead to > multiple > resource reservations. Why? The rfc2833 could be on the same port, no? >Also, > - fid cannot be added by the answerer if the offer didn't include it due > to the > media stream matching rules Correct. That seems less of an issue, since if the offerer lists everything it can do, and the answerer is constrained, it can simply select one codec. > - if fid is included in the offer, but not supported by the answerer, > the handling > may not be all that graceful. Right. I am not wed to this specific mechanism. However, from my hopefully-now-correct understanding of simcap, it seems that it simply doesn't help at all with this issue of doing only one codec at a time. So, options 1 and 2 above are no-go. Another possibility is to add an extension to simcap which allows you to convey this one particular constraint. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 00:36:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20913 for ; Wed, 9 Jan 2002 00:36:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA08732 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 00:36:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07800; Wed, 9 Jan 2002 00:11:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07764 for ; Wed, 9 Jan 2002 00:11:38 -0500 (EST) Received: from hssblrmail.hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20505 for ; Wed, 9 Jan 2002 00:11:34 -0500 (EST) From: mgovind@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hssblrmail.hss.hns.com (8.11.2/8.11.2) with SMTP id g0950X916344; Wed, 9 Jan 2002 10:30:35 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B3C.001BA5EC ; Wed, 9 Jan 2002 10:31:59 +0530 X-Lotus-FromDomain: HSSBLR To: "ShavinderPal Singh" cc: sip@ietf.org Message-ID: <65256B3C.001BA40C.00@sampark.hss.hns.com> Date: Wed, 9 Jan 2002 10:31:54 +0530 Subject: Re: [Sip] Post Dial Delay Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, The time interval between an invite send and the first provisional received is called post dial delay. Please refer the following URL http://www.fokus.gmd.de/events/iptel2000/pr/signaling_talk.pdf Regards mahesh "ShavinderPal Singh" on 01/09/2002 10:37:01 AM To: sip@ietf.org cc: (bcc: Mahesh Govind/HSSBLR) Subject: [Sip] Post Dial Delay Hi, Can any one tell me which rfc caters to the "definition" of "Post Dial delay" in SIP. and how to calculate it? If there is none, can anyone help me how do i verify if my Post Dial delay is less than 1.5 RTT Rgds s eSamsung UMIT, 15th floor, Signature Towers, South City-I, Gurgaon-122001, HR, IND. Ph.: 091-124-6383474 (e 250) _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 01:22:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21541 for ; Wed, 9 Jan 2002 01:22:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18682 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 01:22:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA09143; Wed, 9 Jan 2002 00:53:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA09114 for ; Wed, 9 Jan 2002 00:53:22 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21175 for ; Wed, 9 Jan 2002 00:53:21 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 00:52:52 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE460A3EDC@ftmail> From: "Alan O'Neill" To: "Shieh, Hugh" , "'William Marshall'" , "'sip@ietf.org'" Subject: RE: [Sip] Still issues with preconditions Date: Wed, 9 Jan 2002 00:52:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C198D1.D7F0E4C0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C198D1.D7F0E4C0 Content-Type: text/plain; charset="iso-8859-1" Hi Hugh, thanks for your input So I can definitely see how both the apparently 'simple' pure horizontal and the vertical cases can be covered in the existing doc, I am concerned though that you will open up a rat-hole as different network architectures and QoS models get thrown into the pot. I think we still need a separate doc to cover UA behaviour given specific QoS capabilities and assumptions. As I tried to point out before, even the end to end RSVP case has the non-RSVP cloud to deal with. Does this cause preconditions to fail or pass - this is really not clear and depends on the operators agreements? I think the access only vertical model is the one concrete case and is also is very important (as illustrated by your 3G example) and so can be easily included in the document I feel. Overall though (and maybe best left till later), it would be better if the SDP preconditions documentation defined some assurance oriented terminology that was QoS protocol / topology independent that guided how a UA should interact with SDP preconditions. A separate doc then needs to define how different QoS capabilities and topologies map to these assurance levels. The operator then needs to advise its UAs of their level of assurance for different destinations (intra-domain, inter-domain national, inter-domain international etc. Note this has to be done anyway even in the 'simple' case of the RSVP based horizontal model because the UA needs to know how to react to non-RSVP clouds to different destinations which can be operator / topology / destination specific.. -----Original Message----- From: Shieh, Hugh [mailto:hugh.shieh@attws.com] Sent: 08 January 2002 19:04 To: 'Alan O'Neill'; 'William Marshall'; 'sip@ietf.org' Subject: RE: [Sip] Still issues with preconditions Comments inline. -----Original Message----- From: Alan O'Neill [ mailto:A.ONeill@flarion.com ] Sent: Tuesday, January 08, 2002 4:49 AM To: William Marshall; sip@ietf.org Subject: RE: [Sip] Still issues with preconditions Thanks for the response Bill Comments in-line -----Original Message----- From: William Marshall [ mailto:wtm@research.att.com ] Sent: 27 December 2001 17:16 To: sip@ietf.org Subject: Re: [Sip] Still issues with preconditions Snipped... Should additional terms be defined in manyfolks draft, such as "access" and "backbone" to enable this vertical split? Second, are these the right terms? Comments? AWO> In all cases, the user software should be aware of how it can respond to offered preconditions given its QoS capabilities and its SLA with its operator. This response should be outside the preconditions draft and should instead be in a document discussing the mapping between preconditions and network QoS mechanisms and topologies. The draft should continue to include the simplified horizontal example whilst these mappings are agreed in my book... Hugh> The actual QoS mechanisms are outside the scope of this draft, however, I believe the definition of preconditions is within the scope. As Bill pointed out that the existing definition in the draft (sendonly, recvonly, sendrecv) assumes the horizontal end-to-end model. I see the value of defining the precondition for the vertical model in the draft (to avoid future interoperability problem). In some network, there are "access" and "backbone", the resource in the "backbone" can be statistically provisioned with possibility of semi-dynamic reconfiguration, and the "backbone" resource may not be reserved at per call basis. However, the resource in the "access" part of the network need be reserved at per call basis (e.g., 3G wireless). In this case, UA can only know and need only know if the "access" part of precondition can be satisfied. I would support to define an "access" precondition in the draft. -Hugh Snipped... ------_=_NextPart_001_01C198D1.D7F0E4C0 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Still issues with preconditions
Hi Hugh, thanks for your input
 
So I can definitely see how both the apparently 'simple' pure horizontal and the vertical cases can be covered in the existing doc, I am concerned though that you will open up a rat-hole as different network architectures and QoS models get thrown into the pot. I think we still need a separate doc to cover UA behaviour given specific QoS capabilities and assumptions. As I tried to point out before, even the end to end RSVP case has the non-RSVP cloud to deal with. Does this cause preconditions to fail or pass - this is really not clear and depends on the operators agreements? I think the access only vertical model is the one concrete case and is also is very important (as illustrated by your 3G example) and so can be easily included in the document I feel.
 
Overall though (and maybe best left till later), it would be better if the SDP preconditions documentation defined some assurance oriented terminology that was QoS protocol / topology independent that guided how a UA should interact with SDP preconditions. A separate doc then needs to define how different QoS capabilities and topologies map to these assurance levels. The operator then needs to advise its UAs of their level of assurance for different destinations (intra-domain, inter-domain national, inter-domain international etc. Note this has to be done anyway even in the 'simple' case of the RSVP based horizontal model because the UA needs to know how to react to non-RSVP clouds to different destinations which can be operator / topology / destination specific..
 
 
 
 
-----Original Message-----
From: Shieh, Hugh [mailto:hugh.shieh@attws.com]
Sent: 08 January 2002 19:04
To: 'Alan O'Neill'; 'William Marshall'; 'sip@ietf.org'
Subject: RE: [Sip] Still issues with preconditions

Comments inline.

-----Original Message-----
From: Alan O'Neill [mailto:A.ONeill@flarion.com]
Sent: Tuesday, January 08, 2002 4:49 AM
To: William Marshall; sip@ietf.org
Subject: RE: [Sip] Still issues with preconditions

Thanks for the response Bill

Comments in-line

-----Original Message-----
From: William Marshall [mailto:wtm@research.att.com]
Sent: 27 December 2001 17:16
To: sip@ietf.org
Subject: Re: [Sip] Still issues with preconditions

Snipped...

Should additional terms be defined in manyfolks draft, such as "access"
and "backbone" to enable this vertical split?  Second, are these the
right terms?  Comments?

AWO> In all cases, the user software should be aware of how it can respond
to offered preconditions given its QoS capabilities and its SLA with its
operator. This response should be outside the preconditions draft and should
instead be in a document discussing the mapping between preconditions and
network QoS mechanisms and topologies. The draft should continue to include
the simplified horizontal example whilst these mappings are agreed in my
book...

Hugh> The actual QoS mechanisms are outside the scope of this draft, however, I believe the definition of preconditions is within the scope. As Bill pointed out that the existing definition in the draft (sendonly, recvonly, sendrecv) assumes the horizontal end-to-end model. I see the value of defining the precondition for the vertical model in the draft (to avoid future interoperability problem). In some network, there are "access" and "backbone", the resource in the "backbone" can be statistically provisioned with possibility of semi-dynamic reconfiguration, and the "backbone" resource may not be reserved at per call basis. However, the resource in the "access" part of the network need be reserved at per call basis (e.g., 3G wireless). In this case, UA can only know and need only know if the "access" part of precondition can be satisfied. I would support to define an "access" precondition in the draft.

-Hugh

Snipped...

------_=_NextPart_001_01C198D1.D7F0E4C0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 01:35:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21658 for ; Wed, 9 Jan 2002 01:35:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA19265 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 01:35:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09696; Wed, 9 Jan 2002 01:04:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09664 for ; Wed, 9 Jan 2002 01:03:58 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21339 for ; Wed, 9 Jan 2002 01:03:57 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g09640VZ010700; Wed, 9 Jan 2002 01:04:00 -0500 (EST) Message-ID: <3C3BDD2E.9000100@dynamicsoft.com> Date: Wed, 09 Jan 2002 01:03:26 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jiri Kuthan CC: sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) References: <5.1.0.14.0.20020109034339.026c0b38@mailhost.fokus.gmd.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit After a private discussion between myself, Jiri, and Robert, we concluded on the following proposal: 1. If you are a proxy which can act statelessly (ie., you didn't fork, no tcp, and so on), if you are stateful anyway, you can drop to stateless at any time without sending a CANCEL or anything else. We relax whatever constraints are needed for this. 2. If you can't go stateless, there is a minimum timer C of 3m. A minimum of this size is needed (as opposed to recommended), since otherwise, the UAS won't know how frequently to send 1xx (see below). 3. If a uas needs an extension on timer C, it sends a 1xx. A proxy resets timer C on receipt of a 101-199. The UAS will need to send 1xx at least as frequently as once every 3m. This seems to give us everything we need, and its fairly simple. Agreement? -Jonathan R. Jiri Kuthan wrote: > Summary: C-timer required to be as huge as 3 minutes > eats proxy memory badly while providing questionnable benefits > -> please, don't do that and allow C to be small for > economical proxies; real size of C and handling of C timer can vary > depending on functionality. I think it can be quite > low (4sec?). Sometimes, it must be longer to meet user > expectations (forking ... 32 sec). Special cases > (forking to multiple AA "183 next agent will serve you" > destinations) may ask for even longer C. C in phones > can even be infinite. C may be in hands of users > too (CPL: forward-on-busy with user-driven timeout). > > > -Jiri > > -------- > > In order to be robust, I really want to remove transaction > context asap. This has been nicely hard-wired in protocol > and proxy "randez-vous" concept from SIP's beginning. Who doesn't > agree and wants to make a storage server out of a proxy may > try putting it under heavy load. You'll see that running out > of memory will happen *very* soon (unless you have > terrabytes of fast memory and kilobits of bandwidth). > Making a proxy call-stateful by keeping state during > 5-minutes-long 183 replies is simply too heavy. > >>From this point of view, I would recommend against REQUIRING > C to be long (long: > 32 sec). I think it can be frequently > very short (like 4 sec) without any harm. Specifically, > if the use of state in proxy is retransmission (good if > for example upstream client is on a wireless link and I want > the proxy to deal with retransmissions on its behalf). Then, > - short C timer hurts neither for 2xx (2xx are always relayed > even by stateful proxies) nor for 3xx-6xx which are > mostly automated and come back very quickly > - and if C hits (like with loooong 183), the proxy may discard > transaction > state silently (no CANCEL, no 408) -- upstream and downstream > willing to wait for each other will finish the transaction with > stateless proxy; the great thing is there is no evil intermediary > proxy stopping parties from waiting for each other too early > > It's trickier, if the purpose of state is different > (i.e., if the proxy does more than cleaning transaction > state when C timer hits or a final response comes). > All kinds of forking are a terrifying example. Because we do not want > to put the forking burden on upstream client unexpectedly, > the proxy cannot release transaction context silently > (->CANCEL, 408). And because we do not want to hurt users by > early cancellation, C cannot be too low. 32 sec would be > perhaps enough. Dedicated waiters may push the redial button. > > That's still quite nice, however troubles multiply in special > case of forking to multiple 1xx destinations. What do you do > after C hits (be it 3 minutes), two AA agents keep feeding > you with early media and you are still ready to wait for > a human representative? (I mean from signaling perspective. > I am open to discussion of mixing early media, though ;-) > Cancelling is unhappy in this case -- the caller is still > willing to wait. Silent state releasing is not possible because > that would put forking burden upstream. > > I argue forking to multiple destinations which will return 1xx for > long time and caller will keep waiting is a special case. > So special that whoever configures the proxy to do so will be > aware of how special it is, rise C and buy enough RAM. > Implementers of call distribution by forking might do so, > for (PSTN-free) example. Implementors of standard proxies > might cancel all but one branch before going stateless > if they fear 32 sec is not good enough. > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 01:37:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21683 for ; Wed, 9 Jan 2002 01:37:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA19301 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 01:37:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09645; Wed, 9 Jan 2002 01:02:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09616 for ; Wed, 9 Jan 2002 01:02:55 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21303 for ; Wed, 9 Jan 2002 01:02:53 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0962hJ02874; Wed, 9 Jan 2002 07:02:43 +0100 (MET) Received: from lmf.ericsson.se (lmf00215pc.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0962ghO024043; Wed, 9 Jan 2002 08:02:42 +0200 (EET) Message-ID: <3C3BDD01.8F070AE9@lmf.ericsson.se> Date: Wed, 09 Jan 2002 08:02:41 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Drage, Keith (Keith)" , sip@ietf.org Subject: Re: [Sip] bis draft: Minor NIT on Supported header References: <3C3B654F.6030109@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >According to bis-05, Supported appears: > >(a) in any request when the UAC supports extensions, >(b) OPTIONS request and 200 response >(c) INVITE request and INVITE/200 response > >I think this is reasoable. Would it be useful to allow it also in 18x provisional responses, IF there at some stage will be some "pre-setup" actions that the UAC can take depending on if the remote party supports it or not? The same of course also go for headers like Allow (the UAC may need to know if the remote party supports INFO, for example...), some Accept-Xxx, etc... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 06:23:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02437 for ; Wed, 9 Jan 2002 06:23:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA27324 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 06:23:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26684; Wed, 9 Jan 2002 05:58:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26656 for ; Wed, 9 Jan 2002 05:58:48 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02262 for ; Wed, 9 Jan 2002 05:58:43 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 9 Jan 2002 10:59:12 UT X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Default value for Timer C (was #282) Date: Wed, 9 Jan 2002 11:01:29 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE011224F0@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] Default value for Timer C (was #282) Thread-Index: AcGY1D7wc9i913OWRNSNQ2q/hMXBRwAJ4xdg From: "Jo Hornsby" To: "Jonathan Rosenberg" , "Jiri Kuthan" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA26657 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > After a private discussion between myself, Jiri, and Robert, we > concluded on the following proposal: > > 1. If you are a proxy which can act statelessly (ie., you > didn't fork, > no tcp, and so on), if you are stateful anyway, you can drop to > stateless at any time without sending a CANCEL or anything else. We > relax whatever constraints are needed for this. Good to see that you can only do this if not fork. I found a problem with the previous approach when forking; in the case a late non-2xx was followed by a 2xx. But if INVITE, shouldn't there be some additional requirement that you can't drop to stateless before you've seen a 1xx? Otherwise I can see a request just suddenly disappearing into the ether.... > 2. If you can't go stateless, there is a minimum timer C of 3m. A > minimum of this size is needed (as opposed to recommended), since > otherwise, the UAS won't know how frequently to send 1xx (see below). Okay. > 3. If a uas needs an extension on timer C, it sends a 1xx. A proxy > resets timer C on receipt of a 101-199. The UAS will need to > send 1xx at > least as frequently as once every 3m. Yes, and to be paranoidsafe a good few seconds short of 3min, right? > This seems to give us everything we need, and its fairly simple. > > Agreement? Agreement. - Jo. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 06:55:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02745 for ; Wed, 9 Jan 2002 06:55:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA28248 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 06:55:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27915; Wed, 9 Jan 2002 06:34:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27809 for ; Wed, 9 Jan 2002 06:34:18 -0500 (EST) Received: from hssblrmail.hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02547 for ; Wed, 9 Jan 2002 06:34:12 -0500 (EST) From: kbinu@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hssblrmail.hss.hns.com (8.11.2/8.11.2) with SMTP id g09BNv918099; Wed, 9 Jan 2002 16:53:57 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B3C.003EC160 ; Wed, 9 Jan 2002 16:55:27 +0530 X-Lotus-FromDomain: HSSBLR To: "Jo Hornsby" cc: "Jonathan Rosenberg" , "Jiri Kuthan" , sip@ietf.org Message-ID: <65256B3C.003EC081.00@sampark.hss.hns.com> Date: Wed, 9 Jan 2002 16:55:24 +0530 Subject: RE: [Sip] Default value for Timer C (was #282) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org "Jo Hornsby" on 01/09/2002 04:31:29 PM To: "Jonathan Rosenberg" , "Jiri Kuthan" cc: sip@ietf.org (bcc: K Binu/HSSBLR) Subject: RE: [Sip] Default value for Timer C (was #282) >> 3. If a uas needs an extension on timer C, it sends a 1xx. A proxy >> resets timer C on receipt of a 101-199. The UAS will need to >> send 1xx at >> least as frequently as once every 3m. >Yes, and to be paranoidsafe a good few seconds short >of 3min, right? For this to work reliably over UDP, the 1xx responses used to extend the timer should be sent reliably using 100-rel. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 08:28:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03598 for ; Wed, 9 Jan 2002 08:28:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01161 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 08:28:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00626; Wed, 9 Jan 2002 08:05:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00595 for ; Wed, 9 Jan 2002 08:05:12 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03332 for ; Wed, 9 Jan 2002 08:05:08 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id C93674CE26 for ; Wed, 9 Jan 2002 08:05:10 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA00990; Wed, 9 Jan 2002 08:05:07 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA44424; Wed, 9 Jan 2002 08:05:00 -0500 (EST) Date: Wed, 9 Jan 2002 08:05:00 -0500 (EST) Message-Id: <200201091305.IAA44424@fish.research.att.com> To: sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org kbinu@hss.hns.com wrote: > >> 3. If a uas needs an extension on timer C, it sends a 1xx. A proxy > >> resets timer C on receipt of a 101-199. The UAS will need to > >> send 1xx at > >> least as frequently as once every 3m. > > >Yes, and to be paranoidsafe a good few seconds short > >of 3min, right? > > For this to work reliably over UDP, the 1xx responses used to extend > the timer should be sent reliably using 100-rel. Since 100rel is optional and may not be supported by the UAC, the UAS needs to implement two refresh algorithms.... 1) with Supported: 100rel, resend the 1xx reliably every 2.5min 2) without Supported: 100rel, resend the 1xx every 1min (my rule-of-thumb for non-reliable keepalives is 1/3 of the timeout interval) But, if the UAS knows a final response will come within 3min (like a PSTN gateway, for instance) it need do none of this. This has the benefit of keeping the complexity on the element that is doing 1% of the cases, and nothing additional for the 99%. Sounds like a good solution to me. Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 09:20:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04153 for ; Wed, 9 Jan 2002 09:20:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA02684 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 09:20:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01914; Wed, 9 Jan 2002 08:54:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01886 for ; Wed, 9 Jan 2002 08:54:50 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03820 for ; Wed, 9 Jan 2002 08:54:46 -0500 (EST) Received: from metroliner.cs.columbia.edu (IDENT:root@metroliner.cs.columbia.edu [128.59.19.252]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA11528; Wed, 9 Jan 2002 08:54:48 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by metroliner.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id g09Dsmd32676; Wed, 9 Jan 2002 08:54:48 -0500 Message-ID: <3C3C4CB7.168EF070@cs.columbia.edu> Date: Wed, 09 Jan 2002 08:59:19 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ShavinderPal Singh CC: sip@ietf.org Subject: Re: [Sip] Post Dial Delay References: <89CFEE6120A0224EA07781892EC0B48B43C3B4@esuims01.esamsungumit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit http://www.cs.columbia.edu/sip/papers.html contains a few papers related to SIP performance. ShavinderPal Singh wrote: > > Hi, > > Can any one tell me which rfc caters to the "definition" of "Post Dial > delay" in SIP. and how to calculate it? > If there is none, can anyone help me how do i verify if my Post Dial > delay is less than 1.5 RTT > > Rgds > s > > eSamsung UMIT, 15th floor, Signature Towers, > South City-I, Gurgaon-122001, HR, IND. > Ph.: 091-124-6383474 (e 250) > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 09:49:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04642 for ; Wed, 9 Jan 2002 09:49:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04076 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 09:49:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02911; Wed, 9 Jan 2002 09:26:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02879 for ; Wed, 9 Jan 2002 09:26:20 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04236 for ; Wed, 9 Jan 2002 09:26:16 -0500 (EST) Received: from jku.dynamicsoft.com (dhcp242.fokus.gmd.de [195.37.78.242]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g09EOhY29234; Wed, 9 Jan 2002 15:24:43 +0100 Message-Id: <5.1.0.14.0.20020109150158.027f8f98@iptel.org> X-Sender: jiri@iptel.org (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 09 Jan 2002 15:25:53 +0100 To: "Jo Hornsby" , "Jonathan Rosenberg" From: Jiri Kuthan Subject: RE: [Sip] Default value for Timer C (was #282) Cc: In-Reply-To: <45730E094814E44488F789C1CDED27AE011224F0@GBNEWP0758M.eu.ub iquity.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 12:01 PM 1/9/2002, Jo Hornsby wrote: >But if INVITE, shouldn't there be some additional >requirement that you can't drop to stateless >before you've seen a 1xx? Otherwise I can >see a request just suddenly disappearing into >the ether.... I might be overcoffeinized but I think we're discussing timer C which is started in "proceeding" state, which is entered after 1xx was received. Timer B (which is started before 1xx appears, default value 64*T1=32s) is IMHO long enough. The B-timer handler may be different (it may generate SIP messages) from that for C-timer (which is silent, unless forking or something else very stateful is used). -Jiri _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 09:56:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04816 for ; Wed, 9 Jan 2002 09:56:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA04198 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 09:56:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02778; Wed, 9 Jan 2002 09:21:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02710 for ; Wed, 9 Jan 2002 09:21:29 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04174; Wed, 9 Jan 2002 09:21:23 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA00975; Wed, 9 Jan 2002 06:19:38 -0800 (PST) Message-ID: <3C3C5199.4444C8F2@cisco.com> Date: Wed, 09 Jan 2002 09:20:09 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [MMUSIC] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > >>4. Declare that simcap is overkill for this one problem, and define a > >>single attribute, a=pickone, which says to choose only one of the > >>codecs in the m line. > >>The "I can do one of N, but only one at a time" problem, IMHO, the > >>only > >>capability problem that anyone actually has in real usage. I will note > >>that, in fact, this is the only capabilities question ever asked on > >>sip-implementors. > >> > >>A single attribute would easily solve it. If you want to do rfc2833 > >>along with any one of N other codecs, you could use fid along with > >>this, to include an m line with the rfc2833, and then another m line with > >>the N codecs and the a=pickone attribute. > >> > >> > > > > However that would require use of multiple ports which could lead to > > multiple > > resource reservations. > > Why? The rfc2833 could be on the same port, no? > No. The fid-draft does not allow the different "m=" lines to have the same destination (IP address and port) > > > - if fid is included in the offer, but not supported by the answerer, > > the handling > > may not be all that graceful. > > Right. > > I am not wed to this specific mechanism. However, from my > hopefully-now-correct understanding of simcap, it seems that it simply > doesn't help at all with this issue of doing only one codec at a time. It doesn't solve this particular problem by itself, however it provides a mechanism that can be used to help solve it while remaining backwards compatible. In its present form, you can send an INVITE/offer listing only one codec in the "m=" line, and then include all codecs supported in the capabilites. The answerer can accept this, and then do another re-INVITE picking one or more codecs from the capabilites if you wants to use a different one. > > So, options 1 and 2 above are no-go. > > Another possibility is to add an extension to simcap which allows you to > convey this one particular constraint. > Right. In that case you would probably also define an offer/answer extension that would the answerer to pick codecs from the capabilities, and not just the "m=" line. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 11:11:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06354 for ; Wed, 9 Jan 2002 11:11:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08261 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 11:12:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06549; Wed, 9 Jan 2002 10:38:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06519 for ; Wed, 9 Jan 2002 10:38:38 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05630 for ; Wed, 9 Jan 2002 10:38:36 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A3FEEB2E00FE; Wed, 09 Jan 2002 10:38:38 -0500 Message-ID: <000901c19923$b8602ba0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Jo Hornsby" , "Jonathan Rosenberg" , "Jiri Kuthan" Cc: References: <45730E094814E44488F789C1CDED27AE011224F0@GBNEWP0758M.eu.ubiquity.net> Subject: Re: [Sip] Default value for Timer C (was #282) Date: Wed, 9 Jan 2002 10:38:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I like the proposal very much. more comments below ----- Original Message ----- From: "Jo Hornsby" > > After a private discussion between myself, Jiri, and Robert, we > > concluded on the following proposal: > > > > 1. If you are a proxy which can act statelessly (ie., you > > didn't fork, > > no tcp, and so on), if you are stateful anyway, you can drop to > > stateless at any time without sending a CANCEL or anything else. We > > relax whatever constraints are needed for this. > > Good to see that you can only do this if not > fork. I found a problem with the previous > approach when forking; in the case a late > non-2xx was followed by a 2xx. > > But if INVITE, shouldn't there be some additional > requirement that you can't drop to stateless > before you've seen a 1xx? Otherwise I can > see a request just suddenly disappearing into > the ether.... If we say any value may be used for Timer C unless the proxy has forked, that should cover it. I don't think we should say "you can drop to stateless at any time". It should still follow the INVITE client transaction FSM. Also, there should be some text in Section 16 that talks about what to do when a client transaction terminates due to Timer B or Timer C expiring and under what circumstances you can simply drop the whole "context" without sending a final response. > > > 2. If you can't go stateless, there is a minimum timer C of 3m. A > > minimum of this size is needed (as opposed to recommended), since > > otherwise, the UAS won't know how frequently to send 1xx (see below). > > Okay. > > > 3. If a uas needs an extension on timer C, it sends a 1xx. A proxy > > resets timer C on receipt of a 101-199. The UAS will need to > > send 1xx at > > least as frequently as once every 3m. ----- Original Message ----- From: "William Marshall" > > For this to work reliably over UDP, the 1xx responses used to extend > > the timer should be sent reliably using 100-rel. > > Since 100rel is optional and may not be supported by the UAC, the > UAS needs to implement two refresh algorithms.... > 1) with Supported: 100rel, resend the 1xx reliably every 2.5min > 2) without Supported: 100rel, resend the 1xx every 1min (my rule-of-thumb > for non-reliable keepalives is 1/3 of the timeout interval) > But, if the UAS knows a final response will come within 3min (like > a PSTN gateway, for instance) it need do none of this. > > This has the benefit of keeping the complexity on the element that is > doing 1% of the cases, and nothing additional for the 99%. I agree with Bill that when not using 100rel, the UAS should update every minute in case there is UDP somewhere along the path. cheers, (-:bob _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 12:27:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07698 for ; Wed, 9 Jan 2002 12:27:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12243 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 12:27:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09787; Wed, 9 Jan 2002 11:44:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09742 for ; Wed, 9 Jan 2002 11:44:03 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07018 for ; Wed, 9 Jan 2002 11:44:00 -0500 (EST) Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA23318; Wed, 9 Jan 2002 11:44:02 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g09Gi1mS019421; Wed, 9 Jan 2002 11:44:02 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id g09Gi040019416; Wed, 9 Jan 2002 11:44:00 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15420.29519.464892.878286@grandcentral.cs.columbia.edu> Date: Wed, 9 Jan 2002 11:43:59 -0500 To: Jonathan Rosenberg Cc: sip@ietf.org Subject: Re: [Sip] Open Issue #259: Proxies Honoring Expires In-Reply-To: <3C3A1F28.7000109@dynamicsoft.com> References: <3C2AC076.80708@dynamicsoft.com> <3C3A1F28.7000109@dynamicsoft.com> X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit On Monday, January 7 2002, "Jonathan Rosenberg" wrote to "Jonathan Rosenberg, sip@ietf.org" saying: > There was only one comment on this proposal, from Jo, which agreed to > have proxies ignore Expires. I will therefore consdier the proposal > accepted and the issue closed. I just realized one problem with this, or at least an inconsistency. Sorry I'm somewhat late on this, but it only just occured to me. The SIP CGI spec, RFC 3050, says: 5.7 Local Expiration Handling If a CGI script specifies an Expires header field along with CGI- PROXY-REQUEST, the SIP server SHOULD track the expiration timeout locally as well as sending the message to the remote server. When the timeout expires, the server SHOULD generate a "408 Request Timeout" response. The timeout response SHOULD be handled as specified in section 5.8. At the time the request is timed out, the server SHOULD also transmit CANCEL messages for the request. This allows a SIP CGI script in a proxy server to implement services like "Call Forward No Answer" to trigger after a user-determined time, even if the remote user-agent server is not responding or does not properly handle the Expires header field. While we could allow SIP servers implementing SIP-CGI servers to handle locally-inserted Expires headers differently from remote Expires headers, it seems rather inelegant. Thoughts? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 12:29:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07740 for ; Wed, 9 Jan 2002 12:29:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12282 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 12:29:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11500; Wed, 9 Jan 2002 12:01:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11468 for ; Wed, 9 Jan 2002 12:01:56 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07335 for ; Wed, 9 Jan 2002 12:01:52 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g09H1rW16222; Wed, 9 Jan 2002 11:01:54 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g09H1r103063; Wed, 9 Jan 2002 11:01:53 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA05955; Wed, 9 Jan 2002 11:01:53 -0600 (CST) Reply-To: To: "'Jonathan Rosenberg'" , "Jiri Kuthan" Cc: Subject: RE: [Sip] Default value for Timer C (was #282) Date: Wed, 9 Jan 2002 11:01:51 -0600 Message-ID: <61D824C63B99D311975E00508B0CC98502C66D5D@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <3C3BDD2E.9000100@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree with Jonathan's three-part proposal, as updated by Bill's "transmit once a minute" amendment. /a _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 12:36:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07921 for ; Wed, 9 Jan 2002 12:36:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12894 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 12:36:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11737; Wed, 9 Jan 2002 12:09:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11706 for ; Wed, 9 Jan 2002 12:09:56 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07413 for ; Wed, 9 Jan 2002 12:09:52 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g09H9OVZ011091; Wed, 9 Jan 2002 12:09:25 -0500 (EST) Message-ID: <3C3C7925.7090604@dynamicsoft.com> Date: Wed, 09 Jan 2002 12:08:53 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Lennox CC: sip@ietf.org Subject: Re: [Sip] Open Issue #259: Proxies Honoring Expires References: <15420.29519.464892.878286@grandcentral.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There is nothing that breaks if a proxy follows Expires, its just not needed. I would argue, therefore, that a proxy running CGI would follow it, but otherwise generally not. The proper wording in the text is probably, "A proxy MAY honor Expires in an IVNITE and cancel when that time elapses, but it is generally not needed since the UA will handle it.". -Jonathan R. Jonathan Lennox wrote: > On Monday, January 7 2002, "Jonathan Rosenberg" wrote to "Jonathan > Rosenberg, sip@ietf.org" saying: > > >>There was only one comment on this proposal, from Jo, which agreed to >>have proxies ignore Expires. I will therefore consdier the proposal >>accepted and the issue closed. >> > > I just realized one problem with this, or at least an inconsistency. > Sorry > I'm somewhat late on this, but it only just occured to me. > > The SIP CGI spec, RFC 3050, says: > > 5.7 Local Expiration Handling > > If a CGI script specifies an Expires header field along with CGI- > PROXY-REQUEST, the SIP server SHOULD track the expiration timeout > locally as well as sending the message to the remote server. When > the timeout expires, the server SHOULD generate a "408 Request > Timeout" response. The timeout response SHOULD be handled as > specified in section 5.8. At the time the request is timed out, the > server SHOULD also transmit CANCEL messages for the request. > > This allows a SIP CGI script in a proxy server to implement > services like "Call Forward No Answer" to trigger after a > user-determined time, even if the remote user-agent server > is not responding or does not properly handle the Expires > header field. > > > While we could allow SIP servers implementing SIP-CGI servers to handle > locally-inserted Expires headers differently from remote Expires > headers, it > seems rather inelegant. > > Thoughts? > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 13:13:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08706 for ; Wed, 9 Jan 2002 13:13:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14123 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 13:14:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12780; Wed, 9 Jan 2002 12:31:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12670 for ; Wed, 9 Jan 2002 12:31:01 -0500 (EST) Received: from sm14.texas.rr.com (sm14.texas.rr.com [24.93.35.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07785; Wed, 9 Jan 2002 12:30:56 -0500 (EST) Received: from plong1 (bu24242141-164.austin.rr.com [24.242.141.164]) by sm14.texas.rr.com (8.12.0.Beta16/8.12.0.Beta16) with SMTP id g09HWWu3016872; Wed, 9 Jan 2002 11:32:32 -0600 From: "Paul Long" To: , , Date: Wed, 9 Jan 2002 11:26:49 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C3BD0C5.4030301@dynamicsoft.com> Content-Transfer-Encoding: 7bit Subject: [Sip] RE: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan, Regarding your (rhetorical?) question, "The rfc2833 could be on the same port, no?", there is no SHALL in the statement, but it sounds like RFC 2833 packets are intended to always be on the same port as the audio stream: 3.1/RFC2833: "DTMF digits and named telephone events are carried as part of the audio stream..." Paul Long ipDialog, Inc. -----Original Message----- From: sip-implementors-admin@cs.columbia.edu [mailto:sip-implementors-admin@cs.columbia.edu]On Behalf Of Jonathan Rosenberg Sent: Tuesday, January 08, 2002 11:10 PM To: Flemming Andreasen Cc: sip@ietf.org; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Flemming Andreasen wrote: > >>Offer: >> >>m=audio 8778 RTP/AVP 0 76 >>a=rtpmap:76 telephone-event >>a=sqn:0 >>a=cdsc: 1 audio RTP/AVP 0 76 >>a=cdsc: 3 audio RTP/AVP 1 76 >>a=cdsc: 5 audio RTP/AVP 2 76 >> >>This offer means that the offerer is definitely using PCMU with >> > someone > >>that doesn't understand simcap, but is indicating they can also do >>codecs 1 and 2 (and each of them with rfc2833). The answerer could >> > pick > >>one of those alternate cdsc in the answer: >> > > That's a slight overloading of the simcap semantics which doesn't define > any kind > of grouping of capabilities. Normal usage of simcap would only list a > given > capability once (per media stream at least). If you wanted to express > something > like the above, you would really want to define a new attribute that > could > describe allowable combinations of codecs, however that level of > expressiveness > was outside the scope of the simcap specification. I understand that now as well, once again, my misinterpretation of the simcap spec. Clearly I thought it was solving something that it is not. This leaves a larger hole than I thought. >>4. Declare that simcap is overkill for this one problem, and define a >>single attribute, a=pickone, which says to choose only one of the >>codecs in the m line. >>The "I can do one of N, but only one at a time" problem, IMHO, the >>only >>capability problem that anyone actually has in real usage. I will note >>that, in fact, this is the only capabilities question ever asked on >>sip-implementors. >> >>A single attribute would easily solve it. If you want to do rfc2833 >>along with any one of N other codecs, you could use fid along with >>this, to include an m line with the rfc2833, and then another m line with >>the N codecs and the a=pickone attribute. >> >> > > However that would require use of multiple ports which could lead to > multiple > resource reservations. Why? The rfc2833 could be on the same port, no? >Also, > - fid cannot be added by the answerer if the offer didn't include it due > to the > media stream matching rules Correct. That seems less of an issue, since if the offerer lists everything it can do, and the answerer is constrained, it can simply select one codec. > - if fid is included in the offer, but not supported by the answerer, > the handling > may not be all that graceful. Right. I am not wed to this specific mechanism. However, from my hopefully-now-correct understanding of simcap, it seems that it simply doesn't help at all with this issue of doing only one codec at a time. So, options 1 and 2 above are no-go. Another possibility is to add an extension to simcap which allows you to convey this one particular constraint. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 13:24:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09062 for ; Wed, 9 Jan 2002 13:24:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14364 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 13:24:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13383; Wed, 9 Jan 2002 12:55:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13319 for ; Wed, 9 Jan 2002 12:55:30 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08234; Wed, 9 Jan 2002 12:55:28 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g09Ht9A21035; Wed, 9 Jan 2002 12:55:10 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAA26187 (AUTH pkyzivat); Wed, 9 Jan 2002 12:57:37 -0500 (EST) Message-ID: <3C3C82D9.32BA8081@cisco.com> Date: Wed, 09 Jan 2002 12:50:17 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> <3C3C5199.4444C8F2@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > > It doesn't solve this particular problem by itself, however it provides a > mechanism that can be used to help solve it while remaining backwards > compatible. In its present form, you can send an INVITE/offer listing only one > codec in the "m=" line, and then include all codecs supported in the > capabilites. The answerer can accept this, and then do another re-INVITE > picking one or more codecs from the capabilites if you wants to use a different > one. How about a variant of this - an Invite where the offer includes *no* m= lines, but uses simcap to describe what is available. The recipient would be expected to accept the invite with no media, perhaps also returning capabilities. Then one side or the other need to send a reinvite to establish media. This provides the extra round trip to do negotiation. But it requires significant support from all parties. An alternative that I was going to mention is to precede the INVITE with an OPTIONS request to discover what the other side is capable of. But it suffers from a serious problem - it doesn't establish a dialog, so there is no guarantee that the subsequent INVITE will go to the same place. Paul _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 14:04:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12073 for ; Wed, 9 Jan 2002 14:04:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16262 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 14:04:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15089; Wed, 9 Jan 2002 13:35:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15058 for ; Wed, 9 Jan 2002 13:35:04 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09759 for ; Wed, 9 Jan 2002 13:35:02 -0500 (EST) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g09IYxj50340; Wed, 9 Jan 2002 13:34:59 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Default value for Timer C (was #282) Date: Wed, 9 Jan 2002 13:37:14 -0500 Message-ID: <004501c1993c$a8f1f040$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <200201091305.IAA44424@fish.research.att.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Since 100rel is optional and may not > be supported by the UAC, the UAS needs > to implement two refresh algorithms.... > 1) with Supported: 100rel, resend the > 1xx reliably every 2.5min > 2) without Supported: 100rel, resend > the 1xx every 1min (my rule-of-thumb > for non-reliable keepalives is 1/3 > of the timeout interval) > But, if the UAS knows a final response > will come within 3min (like a PSTN gateway, > for instance) it need do none of this. Sounds fine. The UAS can ring infinitely if it desires. The UAC/proxy can still use the Expires to restrict such activity. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 14:19:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12896 for ; Wed, 9 Jan 2002 14:19:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16612 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 14:19:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15462; Wed, 9 Jan 2002 13:49:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15435 for ; Wed, 9 Jan 2002 13:49:04 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10832 for ; Wed, 9 Jan 2002 13:49:01 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g09ImW601844 for ; Wed, 9 Jan 2002 13:48:32 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g09ImUl10538 for ; Wed, 9 Jan 2002 13:48:30 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 13:46:57 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102AE05@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'sip@ietf.org'" Subject: RE: [Sip] Default value for Timer C (was #282) Date: Wed, 9 Jan 2002 13:47:23 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'll add my support for the proposal for periodic retransmission of 1xx as excerpted below. I can see some uses for that 1xx. This shouldn't be an issue once the offer/answer stuff is done, but we'll have to be totally clear on what goes in the 1xx body and whether changes to SDP are allowed. -----Original Message----- From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] Sent: Tuesday, January 08, 2002 4:59 PM To: jdrosen@dynamicsoft.com; rsparks@dynamicsoft.com Cc: Taylor, Tom-PT [CAR:B800:EXCH]; wtm@research.att.com; sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) Comments inline. Note that this is not one of the major issues, but has been getting alot of attention. We should try to choose a solution quickly. My vote is below. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, January 08, 2002 2:27 PM > To: Robert Sparks > Cc: Hearty, John; 'taylor@nortelnetworks.com'; 'wtm@research.att.com'; > 'sip@ietf.org' > Subject: Re: [Sip] Default value for Timer C (was #282) > > [snip] > > > > 1) Modify the FSMs to restart Timer C for every 1xx > response and then > > have > > the UAS send a 1xx periodically to maintain the transactions in the > > proxies. > > > This one is nice, since it has the effect of requring insertion of > traffic to refresh state. This helps make it immmune from DoS > attacks, > which your second proposal below is. > This solution currently gets my vote (is this a democracy?). The problems prompting some to want the timer to be long would be solved by the user that needs it to be long, the UAS. The minimum could then be some small value such as 32s as originally proposed. [snip] _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 16:42:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16821 for ; Wed, 9 Jan 2002 16:42:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA21032 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 16:42:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20030; Wed, 9 Jan 2002 16:06:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19969 for ; Wed, 9 Jan 2002 16:06:14 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15527; Wed, 9 Jan 2002 16:06:10 -0500 (EST) Message-Id: <200201092106.QAA15527@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org, sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 09 Jan 2002 16:06:10 -0500 Subject: [Sip] I-D ACTION:draft-robinson-mrcp-sip-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using Media Resource Control Protocol over SIP Author(s) : F. Robinson Filename : draft-robinson-mrcp-sip-00.txt Pages : 29 Date : 08-Jan-02 This Draft presents a method for using Media Resource Control Protocol (MRCP) in the body of SIP messages for the purpose of controlling Prompt Players, Text to Speech, and Speech Recognition Engines. Here we present MRCP->SIP as a function of the 'Service Controller,' identified in the decomposition of Application Server Compenent Architecutures for SIP (draft-rosenberg-sip-app-components- 01). The aurthor's believe that MRCP->SIP brings some powerful synergies to bare; rapid development of reliable media resource control, and the highly available, redundant, SIP infrastructure, capable of intelligent resource location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-robinson-mrcp-sip-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-robinson-mrcp-sip-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-robinson-mrcp-sip-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020108150842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-robinson-mrcp-sip-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-robinson-mrcp-sip-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020108150842.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 17:57:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19382 for ; Wed, 9 Jan 2002 17:57:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23100 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 17:57:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22360; Wed, 9 Jan 2002 17:29:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22329 for ; Wed, 9 Jan 2002 17:29:13 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18091 for ; Wed, 9 Jan 2002 17:29:10 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA26811 for ; Wed, 9 Jan 2002 15:29:12 -0700 (MST)] Received: [from az33exb01.corp.mot.com (az33exb01.corp.mot.com [199.2.84.12]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA14958 for ; Wed, 9 Jan 2002 15:29:12 -0700 (MST)] Received: by az33exb01.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 9 Jan 2002 15:29:11 -0700 Message-ID: From: Purcell Michael-QA3001 To: "'sip@ietf.org'" , sip-implementors@cs.columbia.edu Cc: Purcell Michael-QA3001 Date: Wed, 9 Jan 2002 15:29:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In section 8.1.1.8 of draft RFC2543bis-05: it says The option-tags listed MUST only refer to extensions defined in standards track RFCs. This is to prevent servers from insisting that clients implement non-standard, vendor defined features in order to receive service. Extensions defined by experimental and informational RFCs are explicitly excluded from usage with the Supported header in a request, since they too are often used to document vendor defined extensions. The above paragraph excludes the use of header Supported (section 22.35) for "standards track RFCs". From the text "prevent servers from insisting" I assume the exclusion should also apply to headers: Require (section 22.30), and Proxy-Require (section 22.28). That being the case, how do we communicate support for "experimental and informational" extensions? Thanks Mike Purcell _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 9 23:18:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29191 for ; Wed, 9 Jan 2002 23:18:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA02067 for sip-archive@odin.ietf.org; Wed, 9 Jan 2002 23:18:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01349; Wed, 9 Jan 2002 22:56:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01318 for ; Wed, 9 Jan 2002 22:55:58 -0500 (EST) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28761 for ; Wed, 9 Jan 2002 22:55:53 -0500 (EST) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/09/13/01) with ESMTP id MAA14195; Thu, 10 Jan 2002 12:52:10 +0900 (JST) (envelope-from waki.hiroshi@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp by vcs3.rdh.ecl.ntt.co.jp (8.9.3/3.7W/20011217) with ESMTP id MAA12341; Thu, 10 Jan 2002 12:52:10 +0900 (JST) (envelope-from waki.hiroshi@lab.ntt.co.jp) Received: from eclscan3.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/09/02) with ESMTP id MAA20869; Thu, 10 Jan 2002 12:52:09 +0900 (JST) (envelope-from waki.hiroshi@lab.ntt.co.jp) Received: from imf.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id MAA26762; Thu, 10 Jan 2002 12:52:08 +0900 (JST) Received: from pikmin by imf.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id MAA26927; Thu, 10 Jan 2002 12:52:08 +0900 (JST) Message-ID: <0ab201c1998a$2c87fa10$e10a3c81@pikmin> From: "Hiroshi Waki" To: Cc: , References: <3C2B4DBD.9060607@dynamicsoft.com> Date: Thu, 10 Jan 2002 12:52:07 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: changing of media types allowed in offer/answer and SIP open issue #24 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Please let me clarify the consensus concerning SIP open issue #24. According to the consensus and the open issues lists, it is allowed to reactivate disabled media streams. I understand that in order to create a new media stream it is allowed to change the port number of the m-line which has been set to zero. Then in order to modify the port of the stream, is it also allowed to modify the port number of the m-line currently active with an existing media stream ? If the latter is also allowed, the description in the offer-answer-00 draft will be modified to allow the modification of a port number without creating any new media line, won't it? offer-answer-00 draft says in the section 4.3: The port number for a stream MAY be changed. To do this, the offerer creates a new media description, with the port number in the m line different from the corresponding stream in the previous SDP. If only the port number is to be changed, the rest of the media stream description SHOULD remain unchanged. Regards, Hiroshi Waki NTT Network Service Systems Laboratories ----- Original Message ----- From: "Jonathan Rosenberg" To: "Paul Kyzivat" Cc: "'confctrl@isi.edu'" ; Sent: Friday, December 28, 2001 1:35 AM Subject: Re: changing of media types allowed in offer/answer and SIP open issue #24 > Indeed, consensus at IETF 52 was to allow reuse. #24 is considered resolved. > > -Jonathan R. > > Paul Kyzivat wrote: > > > I think the restriction is silly. > > > > I don't see why any piece of code that can keep track of the positional > > assignments, including media that have been refused, should have any > > trouble reusing a previous slot for a new purpose. And changing the > > media type in one step is more or less the same thing. > > > > So why not allow those slots to be reused? > > We may yet see applications where there are enough reinvites with > > changes in media that recycling of slots is important. > > > > Paul > > > > Jonathan Rosenberg wrote: > > > >>Folks, > >> > >>draft-rosenberg-mmusic-sdp-offer-answer-00.txt currently says: > >> > >> The media type (audio, video, etc.) for a stream MAY be changed. This > >> is particularly useful for changing between voice and fax in a single > >> stream, which are both separate media types. To do this, the offerer > >> creates a new media description, with a new media type, in place of > >> the description in the previous SDP which is to be changed. The IP > >> address and port for the stream MAY change, or MAY remain the same. > >> However, the list of payload type numbers for the new codecs MUST be > >> different than any used previously for this stream. > >> > >>This is somewhat linked to the current sip open issue #24 about whether or > >>not you can reuse a media stream "slot" which has been previously disabled > >>with port=0. After all, changing the media type is really the same, more or > >>less, as using a new media stream in place of where an old one was. I think > >>leaning of consensus in the sip group was to disallow such reuse (although I > >>can't remember at this moment what the reasoning was), and that would argue > >>for removing the above capability. > >> > >>Comments or thoughts on this? > >> > >>-Jonathan R. > >> > >>--- > >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > >>Chief Scientist First Floor > >>dynamicsoft East Hanover, NJ 07936 > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > >> > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 02:54:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11346 for ; Thu, 10 Jan 2002 02:54:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA15833 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 02:54:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15065; Thu, 10 Jan 2002 02:23:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15032 for ; Thu, 10 Jan 2002 02:23:21 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11111 for ; Thu, 10 Jan 2002 02:23:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0A7NKVZ011729; Thu, 10 Jan 2002 02:23:21 -0500 (EST) Message-ID: <3C3D4149.5020000@dynamicsoft.com> Date: Thu, 10 Jan 2002 02:22:49 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Purcell Michael-QA3001 CC: "'sip@ietf.org'" Subject: Re: [Sip] rfc2543bis.05 Content-Disposition. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sending "alert" in a re-INVITE makes as much sense as a 180 response to a re-invite, which is not much sense at all (probably a no-op in both cases). Beyond that, you can put in a re-invite anything you could also put in the invite. -Jonathan R. Purcell Michael-QA3001 wrote: > In rfc2543bis.05 for the field, Content-Disposition field > > Is it legal to execute "Re-INVITEs" with content-Disposition set to > "icon", then "alert", then "session"? > > Thanks Mike Purcell > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 09:22:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15307 for ; Thu, 10 Jan 2002 09:22:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA28074 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 09:22:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26919; Thu, 10 Jan 2002 08:49:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA26887 for ; Thu, 10 Jan 2002 08:49:40 -0500 (EST) Received: from mailhost.wellx.com (mailhost.wellx.com [62.161.157.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14669 for ; Thu, 10 Jan 2002 08:49:38 -0500 (EST) Received: from mail.wellx.com by mailhost.wellx.com via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 10 Jan 2002 13:46:16 UT Received: from wellx.com (192.168.1.114 [192.168.1.114]) by srvwellx.wellx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CVPQACYP; Thu, 10 Jan 2002 14:44:31 +0100 Message-ID: <3C3DAC3B.107B48CD@wellx.com> Date: Thu, 10 Jan 2002 15:59:07 +0100 From: Aymeric MOIZARD Reply-To: jack@atosc.org Organization: WellX X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] simple-presence-04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit My question is about the tupple element in draft-ietf-simple-presence-04.txt (Is it the correct mailing list to use?) The draft draft-ietf-simple-presence-04.txt shows examples of "application/cpim-pidf+xml" body where "name" is an attribute of "tuple". open on-hook sip:user@example.com I found that definition in draft-ietf-impp-cpim-pidf-01.txt where "id" is a mandatory attribute for tuple. The example and defintions does not match! Did I choose wrong versions of drafts? Any other explanations? Thanks Aymeric osip.atosc.org _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 13:52:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21237 for ; Thu, 10 Jan 2002 13:52:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09885 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 13:52:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08717; Thu, 10 Jan 2002 13:26:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08685 for ; Thu, 10 Jan 2002 13:26:47 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20739 for ; Thu, 10 Jan 2002 13:26:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0AIQfVZ012119; Thu, 10 Jan 2002 13:26:42 -0500 (EST) Message-ID: <3C3DDCC0.3080306@dynamicsoft.com> Date: Thu, 10 Jan 2002 13:26:08 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Tom-PT Taylor CC: "'sip@ietf.org'" Subject: Re: [Sip] Default value for Timer C (was #282) References: <4D79C746863DD51197690002A52CDA000102AE05@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit OK, great. I think there is consensus on this, which is the following slightly amended proposal: 1. If you are a proxy which can act statelessly (ie., you didn't fork, no tcp, and so on), if you are stateful anyway, you can drop to stateless at any time without sending a CANCEL or anything else. We relax whatever constraints are needed for this. 2. If you can't go stateless, there is a minimum timer C of 3m. A minimum of this size is needed (as opposed to recommended), since otherwise, the UAS won't know how frequently to send 1xx (see below). 3. If a uas needs an extension on timer C, it sends a 1xx. A proxy resets timer C on receipt of a 101-199. The UAS will need to send 1xx at least as frequently as once every 1m, allowing for several 1xx to be lost. Thanks for everyones cooperation in commenting and working towards a solution. -Jonathan R. Tom-PT Taylor wrote: > I'll add my support for the proposal for periodic retransmission of 1xx > as > excerpted below. I can see some uses for that 1xx. This shouldn't be > an > issue once the offer/answer stuff is done, but we'll have to be totally > clear on what goes in the 1xx body and whether changes to SDP are > allowed. > > -----Original Message----- > From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] > Sent: Tuesday, January 08, 2002 4:59 PM > To: jdrosen@dynamicsoft.com; rsparks@dynamicsoft.com > Cc: Taylor, Tom-PT [CAR:B800:EXCH]; wtm@research.att.com; sip@ietf.org > Subject: RE: [Sip] Default value for Timer C (was #282) > > > Comments inline. Note that this is not one of the major issues, but has > been getting alot of attention. We should try to choose a solution > quickly. > My vote is below. > > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Tuesday, January 08, 2002 2:27 PM >>To: Robert Sparks >>Cc: Hearty, John; 'taylor@nortelnetworks.com'; 'wtm@research.att.com'; >>'sip@ietf.org' >>Subject: Re: [Sip] Default value for Timer C (was #282) >> >> >> > [snip] > >> >>>1) Modify the FSMs to restart Timer C for every 1xx >>> >>response and then >> >>>have >>>the UAS send a 1xx periodically to maintain the transactions in the >>>proxies. >>> >> >>This one is nice, since it has the effect of requring insertion of >>traffic to refresh state. This helps make it immmune from DoS >>attacks, >>which your second proposal below is. >> >> > > This solution currently gets my vote (is this a democracy?). The > problems > prompting some to want the timer to be long would be solved by the user > that > needs it to be long, the UAS. The minimum could then be some small > value > such as 32s as originally proposed. > > [snip] > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 13:53:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21280 for ; Thu, 10 Jan 2002 13:52:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09916 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 13:52:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09335; Thu, 10 Jan 2002 13:31:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09306 for ; Thu, 10 Jan 2002 13:31:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20871 for ; Thu, 10 Jan 2002 13:31:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0AIVFVZ012122; Thu, 10 Jan 2002 13:31:17 -0500 (EST) Message-ID: <3C3DDDD2.1080909@dynamicsoft.com> Date: Thu, 10 Jan 2002 13:30:42 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: John.Hearty@Level3.com CC: sip@ietf.org Subject: Re: [Sip] Open Issue #139: re-INVITE Glare References: <17052388D394D411803900508BDFFAF601B37111@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Great. I will amend the proposal, so that it uses Brett's modified timer setting (one side chooses to retry in 0-2s, the other in 2-4s, based on a belief in which side is the originator of the dialog). Issue resolved. Thanks, Jonathan R. John.Hearty@Level3.com wrote: > Your points are all valid. I cannot think of a good alternative to be > certain both sides agree there is glare. Since the probability of glare > is > not particularly high anyway, and in the interests of timely resolution > of > open issues, the latest timer solution seems acceptable. > > John Hearty > Level3 > > >>-----Original Message----- >>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Tuesday, January 01, 2002 9:42 PM >>To: Hearty, John >>Cc: orton@nortelnetworks.com; brett@broadsoft.com; sip@ietf.org >>Subject: Re: [Sip] Open Issue #139: re-INVITE Glare >> >> >> >> >>John.Hearty@Level3.com wrote: >> >> >>>>I actually posted this to the list over a year back: >>>> >>>> I'm afraid this solution does not work as specified. It >>>> >>only works >> >>>> if both sides agree they are in a glare situation. Consider the >>>> following case. A sends a reinvite to B. B receives it, >>>>and responds >>>> with a 200. This response takes a while to get to A. >>>> >>Now, B sends a >> >>>> re-INVITE to A (as far as B is concerned, the reinvite >>>> >>it received >> >>>> has been responded to, thus there is no glare, and it can >>>>send a new >>>> re-INVITE). A receives that re-invite. A thinks there is >>>> >>glare, and >> >>>> decides its the winner, so it responds. Then, A gets the non-500 >>>> response from B. Now A is really confused. >>>> >>>> >>>This scenario would require packet re-ordering, with B's >>> >>200 arriving at >> >>>A >>>after B's re-Invite. These are both going to the same >>> >>place, and these >> >>>days, the likelyhood of packets between the same two places getting >>>re-ordered is not that high. Granted, there are probabally proxies >>>between >>>increasing the likelyhood of the messages getting >>> >>re-ordered. However, >> >>>do >>>we really want to discard a cleaner solution for a small >>> >>percentage of >> >>>negative scenarios? I have seen arguments in other threads against >>>solving >>>problems resulting when the network is totally hosed. >>> >> >>Its not reordering, so much as packet loss. All it takes is >>one or two >>lost 200 OK's, and the above scenario can happen without the network >>doing any packet reordering. >> >> >> >>> >>>> You could argue that B shouldn't even send that >>>> >>re-INVITE until the >> >>>> ACK is received for the re-INVITE B got first. However, there is >>>> still a race condition that makes it not work, although its even >>>> less likely. Heres the case: A sends a re-invite to B that gets >>>> lost. B sends a re-invite to A. A sees glare, and >>>> >>decides A should >> >>>> win, so it responds with a 200 OK. B ACKs, and A gets the >>>>ACK. Then, that >>>> lost reinvite arrives at B. B thinks everything is fine, >>>> >>since the >> >>>> previous reinvite it sent has been ACKed. So, it sends a 200 >>>> OK. Now, A is once again confused. It expected B to reject >>>>that first >>>> INVITE, since A was declared the winner. >>>> >>>> >>>B better not think everything is fine, it just got an >>> >>Invite with the >> >>>same >>>Cseq it just used. >>> >> >>Same CSeq? These are in opposite directions. There is no relationship >>between the CSeq in each direction. >> >> >>>Again, this scenario requires packet re-ordering >>>between >>>the same end points, not a highly likely thing to happen. >>> >> >>Packet loss is the problem, as I mentioned above. >> >> The proposed >> >>>argument of not re-Inviting until after ACK seems to tie back to the >>>overlapping Invite open issue #113, I am unclear where that left off >>>other >>>than it got ugly quickly and it seemed too late to resolve >>> >>in bis. This >> >>>might be another reason to avoid overlapping Invites unless >>> >>it becomes a >> >>>pressing need. I still feel we should avoid timers to >>> >>resolve glare if >> >>>we >>>can. They are inefficient. >>> >> >>I welcome alternatives, but I am pretty sure anything that relies on >>both sides agreeing that there was glare is not going to work. >> >> >> >>> >>>>Now, Brett had proposed a variant: >>>> >>>> >>>> >>>>>However I agree with John that something >>>>>should produce an early winner of the >>>>>re-INVITE glare. How about allowing the >>>>>owner of the Call-ID to have the random >>>>>0 to 2 seconds (by 10ms) and the other >>>>>gets random between 2.1 and 4 seconds >>>>>(by 10ms)? Session refreshing induced >>>>>reinvites should choose higher random >>>>>backoff intervals assuming that there >>>>>is time left to accommodate it. >>>>> >>>>> >>>>> >>>>There are cases where the "owner of the call-id" is also not known. >>>>Consider the case where A calls B. A crashes. B detects >>>> >>this through >> >>>>ICMP on the media channel, and does a re-INVITE to re-establish. A >>>>backup for A reconstitutes the state, and the call >>>> >>continues. Now, A >> >>>>thinks that B owns the Call-ID, and B thinks A owns it. Hmmm. >>>> >>>> >>> If A is smart enough to reconstitute state, it ought to be >>> >>smart enough >> >>>to >>>know if it owned the Call-ID. This could be a condition of >>> >>the proposal >> >>>for >>>issue #207. Otherwise, we don't have to stick with the >>> >>"owner of the >> >>>Call-ID", there are other things unique to the transactions >>> >>that could >> >>>be >>>used to derive a definitive early winner. >>> >> >>Thats fair enough. This was definitely a minor point in >>either case; I >>thought Brett's proposal was reasonable, this issue aside. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >>Chief Scientist First Floor >>dynamicsoft East Hanover, NJ 07936 >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PH: (973) 952-5000 >>http://www.dynamicsoft.com >> >> > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 13:53:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21286 for ; Thu, 10 Jan 2002 13:53:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09930 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 13:53:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09381; Thu, 10 Jan 2002 13:32:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09354 for ; Thu, 10 Jan 2002 13:32:38 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20877 for ; Thu, 10 Jan 2002 13:32:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0AIWcVZ012125; Thu, 10 Jan 2002 13:32:38 -0500 (EST) Message-ID: <3C3DDE25.1090706@dynamicsoft.com> Date: Thu, 10 Jan 2002 13:32:05 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #370: RTT estimates for 2xx retransmits References: <3C32A340.5090008@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There were no comments on this, so I will assume consensus is to accept the proposal, and make no changes to the text as it stands. -Jonathan R. Jonathan Rosenberg wrote: > Section 13.3.1.4 talks about how the uas core retransmits the 2xx with > intervals > that start at t1 and double until t2. These timers should ideally be > rtt-tuned, > but they are NOT the same measurements as the ones used for sending > requests. > The reason is that these are almost always through intermediaries, so > the rtt > estimate is from uas to uac through N proxies. It could be done by > including a > Timestamp in the 2xx, which is mirrored in the ACK. However, its not > clear how > to scope that measurement. Note that a similar thing exists for > 1xx/PRACK. > > Should we say anything about this? > > > My proposal is NO, since I think that any such estimation is impossible > to be done usefully. > > -Jonathan R. > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 14:03:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21519 for ; Thu, 10 Jan 2002 14:03:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10548 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 14:03:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09533; Thu, 10 Jan 2002 13:38:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09503 for ; Thu, 10 Jan 2002 13:38:48 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20976 for ; Thu, 10 Jan 2002 13:38:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0AIcfVZ012141; Thu, 10 Jan 2002 13:38:41 -0500 (EST) Message-ID: <3C3DDF90.9040306@dynamicsoft.com> Date: Thu, 10 Jan 2002 13:38:08 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] Open Issue #290: Registrar increasing registration life time References: <001101c19495$2b65bbd0$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Brett makes some excellent points. Thanks for recapping the old discussion. Based on this, I would therefore propose to keep what we have, and allow the registrar to increase the durations, indicating that an exception should be made for 0, and document that this means setting registrations with expires is not the right way to get call services. Let us resolve this issue finally. -Jonathan R. Brett Tate wrote: >>The ONLY thing solved by the increasing-duration >>capability was to handle compliant, but >>"overly zealous" user agents. There is no >>disagreement that it doesn't help with dos >>attacks. >> >>Perhaps the right solution, then, is to allow >>registrars to only decrease, and to provide an >>error response code to provide a general >>"you're sending too fast, slow down" capability, >>which would also be helpful for SUBSCRIBE, for >>example, which will suffer the same problem. >> >>Comments? >> > > All of these same points were raised last summer > around the time we were also trying to address > short Session-Expires. > (Sorry, I couldn't reach > http://lists.bell-labs.com/pipermail/sip/ > to link the thread). > > At that time, the decision was that the REGISTER > was not intend to register services like temporary > call forwarding through the use of the expires > header or parameter. Nobody was overly opposed > to the backward compatibility issue with rfc2543. > People didn't really think reallocation of a > contact to a different subscriber would really > be an issue. > > The problem with returning an error response is > that non-bis compliant UAC's would reduce the > response to 400. Thus it might actually produce > more registrations and restrict the user from > receiving calls until customer support > communicates what the timer should be. > > The problem with UAS extending the timer is that > non-bis compliant UAC might continue to register > based upon original expires. This isn't that > big a deal. The registrar could kick off an > email, auto-call, or begin rejecting the REGISTER > to ensure the situation gets corrected. > > Ultimately, I don't mind which solution is > chosen, I would just like to see it closed > for good. If a vote is required, I'd prefer > allowing the registrar to modify the > expires however it desires as long as it > gets communicated back to the UAC so it knows > when to refresh or cancel the registration. > This would help avoid the need for user > reconfiguration since the UAC gives the > preference and the UAS gives the decision. > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 14:23:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22018 for ; Thu, 10 Jan 2002 14:23:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11125 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 14:23:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10647; Thu, 10 Jan 2002 14:04:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10616 for ; Thu, 10 Jan 2002 14:04:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21563 for ; Thu, 10 Jan 2002 14:04:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0AJ4GVZ012174; Thu, 10 Jan 2002 14:04:17 -0500 (EST) Message-ID: <3C3DE590.9050504@dynamicsoft.com> Date: Thu, 10 Jan 2002 14:03:44 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org, John.Hearty@Level3.com Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <3C3A8BEA.80F74FB6@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit CHANGE IN DIRECTION OF THIS ISSUE - read below!! (I suspect most have not been following this thread) Christer Holmberg wrote: > Hi, >>>Q3: >>> >>>Also, the draft doesn't say anything about the case where BOTH nodes >>>detect the media failure. Assume that both UA1 and UA2 detects the >>>media failure. The re-INVITE sent by UA1 may end up at UA3, and the >>>re-INVITE >>>sent by UA2 may end up at UA4, in which case things may get messy. One >>>of my phones may send the re-INVITE, and suddenly my other phone >>>starts ringing... or something like that... >>> >>See above. Requests are not generally routed to alternates >>gratuitously. >> >>The above case would only happen if both ends actually fail >>simultaneously. I am not that concerned about this situation. >> > > NONE of the end nodes have to fail. BOTH may, however, detect the media > failure simuntaneously, due to an error in the IP network, in which case > BOTH would generate re-INVITE - and what I described above may happend. True, but you are asusming above that those re-invites are routed to different servers. They are regular in-dialog requests, and unless there has been an element failure that invokes srv or failure processing at a proxy, it will be delivered to the proper UA. >>The issue is simple - on detection of a media failure, do we specify >>that a UA SHOULD generate a re-INVITE, in order to allow the far end to >>reconsistute session and dialog state in the event the media failure >>was >>due to a failed endpoint? The cost is low, the potential benefits are >>high. I say yes. >> > > What do you mean by "failed endpoint"? A SIP endpoint? Does this mean > that the node have to check that the ICMP message actually came from the > remote SIP user (and not, for example, from an intermediate router) > before it decides if to send a re-INVITE or not? No, you are reading too much into the statement. > > I do NOT have anything against adding what you propose as a SHOULD to > bis, but I would like the text to say that it should be done only when > the client is pretty sure that the remote SIP endpoint really has > failed, and that a re-INVITE would do any good. Otherwise the network > could be overloaded with "useless" re-INVITEs when there is a major > failure in the IP network, but the SIP nodes are working just fine... In > this case I think we would even avoid many of the issues above (Q3, for > example). Now, THIS is a good point. A network failure, could trigger a storm of INVITEs which might only make the situation worse. OK, I am willing to concede that use of the mecahnism when you don't know that it is the endpoint that failed, could be quite bad. So, since: (1) it could actually hurt alot (2) it is possible to add this later through an extension (Supported: reconstitute in INVITE, Require: reconstitute in 2xx) (3) you can't COUNT on it being there anyway, since its not in rfc2543 or many versions of bis I will back off and we will punt this to an extension if people still feel it is valuable, but we do need to do some work to make sure that it works properly, and I don't want to hold up bis on it. In place of this, I would propose that the proper endpoint behavior on detection of media failure is a matter of local policy; however, automated generation of BYE or re-INVITE is not recommended to avoid flooding the network with traffic (the user will likely hang up themselves). If these messages do need to be sent automatically, they should be sent after some randomized interval. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 14:27:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22084 for ; Thu, 10 Jan 2002 14:27:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11195 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 14:27:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10746; Thu, 10 Jan 2002 14:09:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10717 for ; Thu, 10 Jan 2002 14:09:22 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21656 for ; Thu, 10 Jan 2002 14:09:20 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0AJ6wvw026501; Thu, 10 Jan 2002 14:06:58 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Jan 2002 14:08:43 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E942@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time Date: Thu, 10 Jan 2002 14:08:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I still feel strongly that the registrar should only shorten the lifetime of the registration. The spirit should be negotiation, not server assignment. With the registrar extending the expiration, there is no way for the client to object to an excessive time (requiring it to remember when it really wanted to "deregister" defeats the whole purpose of softstate). RjS > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, January 10, 2002 12:38 PM > To: brett@broadsoft.com > Cc: sip@ietf.org > Subject: Re: [Sip] Open Issue #290: Registrar increasing registration > life time > > > Brett makes some excellent points. Thanks for recapping > the old discussion. > > Based on this, I would therefore propose to keep what > we have, and allow the registrar to increase the durations, > indicating that an exception should be made for 0, and > document that this means setting registrations with > expires is not the right way to get call services. > > Let us resolve this issue finally. > > -Jonathan R. > > Brett Tate wrote: > > >>The ONLY thing solved by the increasing-duration > >>capability was to handle compliant, but > >>"overly zealous" user agents. There is no > >>disagreement that it doesn't help with dos > >>attacks. > >> > >>Perhaps the right solution, then, is to allow > >>registrars to only decrease, and to provide an > >>error response code to provide a general > >>"you're sending too fast, slow down" capability, > >>which would also be helpful for SUBSCRIBE, for > >>example, which will suffer the same problem. > >> > >>Comments? > >> > > > > All of these same points were raised last summer > > around the time we were also trying to address > > short Session-Expires. > > (Sorry, I couldn't reach > > http://lists.bell-labs.com/pipermail/sip/ > > to link the thread). > > > > At that time, the decision was that the REGISTER > > was not intend to register services like temporary > > call forwarding through the use of the expires > > header or parameter. Nobody was overly opposed > > to the backward compatibility issue with rfc2543. > > People didn't really think reallocation of a > > contact to a different subscriber would really > > be an issue. > > > > The problem with returning an error response is > > that non-bis compliant UAC's would reduce the > > response to 400. Thus it might actually produce > > more registrations and restrict the user from > > receiving calls until customer support > > communicates what the timer should be. > > > > The problem with UAS extending the timer is that > > non-bis compliant UAC might continue to register > > based upon original expires. This isn't that > > big a deal. The registrar could kick off an > > email, auto-call, or begin rejecting the REGISTER > > to ensure the situation gets corrected. > > > > Ultimately, I don't mind which solution is > > chosen, I would just like to see it closed > > for good. If a vote is required, I'd prefer > > allowing the registrar to modify the > > expires however it desires as long as it > > gets communicated back to the UAC so it knows > > when to refresh or cancel the registration. > > This would help avoid the need for user > > reconfiguration since the UAC gives the > > preference and the UAS gives the decision. > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 14:32:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22189 for ; Thu, 10 Jan 2002 14:31:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA11658 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 14:32:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10893; Thu, 10 Jan 2002 14:13:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10860 for ; Thu, 10 Jan 2002 14:13:09 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21774 for ; Thu, 10 Jan 2002 14:13:07 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0AJCxVZ012180; Thu, 10 Jan 2002 14:12:59 -0500 (EST) Message-ID: <3C3DE79B.5090201@dynamicsoft.com> Date: Thu, 10 Jan 2002 14:12:27 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Charles Eckel CC: Shail Bhatnagar , Brian Stucker , Scott Orton , "'Kiranmai Pavoori'" , vkg , sip Subject: Re: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! References: <3C38FBEB.96DE1980@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit OK, great to hear! Well then, it looks like we can indeed go full steam ahead, and totally remove absolute times in Expires from the specification. I would like to do that as well for Retry-After, I assume if people are OK with this for Expires it will be OK for Retry-After. Most likely I will also add text that says "if you see a malformed value in the expires header or param (which an absolute time would be), assume a value of 3600. This assures that things would still even work, albeit not quite right, if someone still had an old registrar around that was sending absolute times. Thanks, Jonathan R. Charles Eckel wrote: > Jonathan, > > We can/will make the necessary modifications to comply with the > depreciation, so you have the green light from Cisco. > Shail, thanks for clarifying the issue and the necessary fix. > > Cheers > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 15:03:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22733 for ; Thu, 10 Jan 2002 15:03:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA12891 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 15:03:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12052; Thu, 10 Jan 2002 14:43:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11949 for ; Thu, 10 Jan 2002 14:43:53 -0500 (EST) Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22378 for ; Thu, 10 Jan 2002 14:43:50 -0500 (EST) Message-ID: <20020110194346.88944.qmail@web11608.mail.yahoo.com> Received: from [208.237.135.12] by web11608.mail.yahoo.com via HTTP; Thu, 10 Jan 2002 11:43:46 PST Date: Thu, 10 Jan 2002 11:43:46 -0800 (PST) From: Sean Olson Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time To: Robert Sparks , Jonathan Rosenberg , brett@broadsoft.com Cc: sip@ietf.org In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E942@DYN-TX-EXCH-001.dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org But this isn't negotiation. The expiration value defines state/service in the server. Ultimately it is completely up to the registrar to determine how long it will maintain state for. If the server decides to increase the value, the only impact to the client is that it needs to send a de-REGISTER if it truly wants a smaller registration period. I don't think this is significant because the client will likely have implemented logic to handle re-REGISTERs anyways (i.e. the client has a notion of how long it's registration state is valid for and is maintaining a timer of sorts to determine when to send a re-REGISTER.) I strongly agree with the notion of soft-state. I would go further and say that registration is actually "fuzzy" state meaning that we are not really talking about well defined or crisp time boundaries here. The difference between holding state for 10 seconds or 15 seconds is not significant for instance. And as Jonathan pointed out, services should not depend on such crisp values. I don't believe that having to send a de/re-REGISTER is a violation of soft state. --- Robert Sparks wrote: > I still feel strongly that the registrar should only > shorten > the lifetime of the registration. The spirit should > be > negotiation, not server assignment. With the > registrar extending > the expiration, there is no way for the client to > object to > an excessive time (requiring it to remember when it > really > wanted to "deregister" defeats the whole purpose of > softstate). > > RjS > > > -----Original Message----- > > From: Jonathan Rosenberg > [mailto:jdrosen@dynamicsoft.com] > > Sent: Thursday, January 10, 2002 12:38 PM > > To: brett@broadsoft.com > > Cc: sip@ietf.org > > Subject: Re: [Sip] Open Issue #290: Registrar > increasing registration > > life time > > > > > > Brett makes some excellent points. Thanks for > recapping > > the old discussion. > > > > Based on this, I would therefore propose to keep > what > > we have, and allow the registrar to increase the > durations, > > indicating that an exception should be made for 0, > and > > document that this means setting registrations > with > > expires is not the right way to get call services. > > > > Let us resolve this issue finally. > > > > -Jonathan R. > > > > Brett Tate wrote: > > > > >>The ONLY thing solved by the increasing-duration > > > >>capability was to handle compliant, but > > >>"overly zealous" user agents. There is no > > >>disagreement that it doesn't help with dos > > >>attacks. > > >> > > >>Perhaps the right solution, then, is to allow > > >>registrars to only decrease, and to provide an > > >>error response code to provide a general > > >>"you're sending too fast, slow down" capability, > > > >>which would also be helpful for SUBSCRIBE, for > > >>example, which will suffer the same problem. > > >> > > >>Comments? > > >> > > > > > > All of these same points were raised last summer > > > around the time we were also trying to address > > > short Session-Expires. > > > (Sorry, I couldn't reach > > > http://lists.bell-labs.com/pipermail/sip/ > > > to link the thread). > > > > > > At that time, the decision was that the REGISTER > > > was not intend to register services like > temporary > > > call forwarding through the use of the expires > > > header or parameter. Nobody was overly opposed > > > to the backward compatibility issue with > rfc2543. > > > People didn't really think reallocation of a > > > contact to a different subscriber would really > > > be an issue. > > > > > > The problem with returning an error response is > > > that non-bis compliant UAC's would reduce the > > > response to 400. Thus it might actually produce > > > more registrations and restrict the user from > > > receiving calls until customer support > > > communicates what the timer should be. > > > > > > The problem with UAS extending the timer is that > > > non-bis compliant UAC might continue to register > > > based upon original expires. This isn't that > > > big a deal. The registrar could kick off an > > > email, auto-call, or begin rejecting the > REGISTER > > > to ensure the situation gets corrected. > > > > > > Ultimately, I don't mind which solution is > > > chosen, I would just like to see it closed > > > for good. If a vote is required, I'd prefer > > > allowing the registrar to modify the > > > expires however it desires as long as it > > > gets communicated back to the UAC so it knows > > > when to refresh or cancel the registration. > > > This would help avoid the need for user > > > reconfiguration since the UAC gives the > > > preference and the UAS gives the decision. > > > > > > > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle > Rock Avenue > > Chief Scientist First > Floor > > dynamicsoft East > Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) > 952-5050 > > http://www.jdrosen.net PH: (973) > 952-5000 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > Sip mailing list > http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > Protocol > > Use sip-implementors@cs.columbia.edu for questions > on current sip > > Use sipping@ietf.org for new developments on the > application of sip > > > > _______________________________________________ > Sip mailing list > http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip ===== -- Sean Olson __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 15:10:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22909 for ; Thu, 10 Jan 2002 15:10:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13103 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 15:10:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12202; Thu, 10 Jan 2002 14:52:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12173 for ; Thu, 10 Jan 2002 14:52:13 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22504 for ; Thu, 10 Jan 2002 14:52:06 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id TAA08405; Thu, 10 Jan 2002 19:49:34 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id TAA01300; Thu, 10 Jan 2002 19:51:53 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 12:51:48 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B37126@n0214idc1.oss.level3.com> To: jdrosen@dynamicsoft.com, christer.holmberg@lmf.ericsson.se Cc: sip@ietf.org Subject: RE: [Sip] Open Issue #207: Handling of session failures Date: Thu, 10 Jan 2002 12:51:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Comments inline. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, January 10, 2002 12:04 PM > To: Christer Holmberg > Cc: sip@ietf.org; Hearty, John > Subject: Re: [Sip] Open Issue #207: Handling of session failures > > > CHANGE IN DIRECTION OF THIS ISSUE - read below!! (I suspect most have > not been following this thread) > > > > > > Christer Holmberg wrote: > > > Hi, > > >>>Q3: > >>> > >>>Also, the draft doesn't say anything about the case where > BOTH nodes > >>>detect the media failure. Assume that both UA1 and UA2 detects the > >>>media failure. The re-INVITE sent by UA1 may end up at UA3, and the > >>>re-INVITE > >>>sent by UA2 may end up at UA4, in which case things may > get messy. One > >>>of my phones may send the re-INVITE, and suddenly my other phone > >>>starts ringing... or something like that... > >>> > >>See above. Requests are not generally routed to alternates > >>gratuitously. > >> > >>The above case would only happen if both ends actually fail > >>simultaneously. I am not that concerned about this situation. > >> > > > > NONE of the end nodes have to fail. BOTH may, however, > detect the media > > failure simuntaneously, due to an error in the IP network, > in which case > > BOTH would generate re-INVITE - and what I described above > may happend. > > > True, but you are asusming above that those re-invites are routed to > different servers. They are regular in-dialog requests, and > unless there > has been an element failure that invokes srv or failure > processing at a > proxy, it will be delivered to the proper UA. > > > >>The issue is simple - on detection of a media failure, do we specify > >>that a UA SHOULD generate a re-INVITE, in order to allow > the far end to > >>reconsistute session and dialog state in the event the media failure > >>was > >>due to a failed endpoint? The cost is low, the potential > benefits are > >>high. I say yes. > >> > > > > What do you mean by "failed endpoint"? A SIP endpoint? Does > this mean > > that the node have to check that the ICMP message actually > came from the > > remote SIP user (and not, for example, from an intermediate router) > > before it decides if to send a re-INVITE or not? > > > No, you are reading too much into the statement. > > > > > > I do NOT have anything against adding what you propose as a > SHOULD to > > bis, but I would like the text to say that it should be > done only when > > the client is pretty sure that the remote SIP endpoint really has > > failed, and that a re-INVITE would do any good. Otherwise > the network > > could be overloaded with "useless" re-INVITEs when there is a major > > failure in the IP network, but the SIP nodes are working > just fine... In > > this case I think we would even avoid many of the issues > above (Q3, for > > example). > > > Now, THIS is a good point. > > A network failure, could trigger a storm of INVITEs which might only > make the situation worse. > > OK, I am willing to concede that use of the mecahnism when you don't > know that it is the endpoint that failed, could be quite bad. > > So, since: > > (1) it could actually hurt alot It is not clear to me this would hurt alot. The extra SIP messages are likely to be insignificant compared to all the RTP and ICMPs bouncing around. I'll conceed they may not be going exactly the same place, so some network segments could get pounded that previously saw little traffic. > (2) it is possible to add this later through an extension (Supported: > reconstitute in INVITE, Require: reconstitute in 2xx) > (3) you can't COUNT on it being there anyway, since its not > in rfc2543 > or many versions of bis > > I will back off and we will punt this to an extension if people still > feel it is valuable, but we do need to do some work to make > sure that it > works properly, and I don't want to hold up bis on it. > > In place of this, I would propose that the proper endpoint > behavior on > detection of media failure is a matter of local policy; however, > automated generation of BYE or re-INVITE is not recommended to avoid > flooding the network with traffic (the user will likely hang up > themselves). If these messages do need to be sent automatically, they > should be sent after some randomized interval. > My main goal was to have the end receiving ICMPs do something to figure out if there was a valid session, and either stop sending RTP or reconstitute the session. Anything would be better than no action at all. I'm a bit concerned that leaving this up to local policy = no action at all. At this point it appears the bis is not the place to address this problem. I agree with the randomized interval for automated generation of messages though. John Hearty Level3 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 15:13:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23008 for ; Thu, 10 Jan 2002 15:13:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13209 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 15:13:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12308; Thu, 10 Jan 2002 14:54:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12277 for ; Thu, 10 Jan 2002 14:54:37 -0500 (EST) Received: from localhost.localdomain ([63.110.3.150]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22541 for ; Thu, 10 Jan 2002 14:54:34 -0500 (EST) Received: from rocinante (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g0AJFIF02138; Thu, 10 Jan 2002 13:16:38 -0600 Subject: Re: [Sip] Open Issue #290: Registrar increasing registration life time From: Ben Campbell To: Jonathan Rosenberg Cc: brett@broadsoft.com, sip@ietf.org In-Reply-To: <3C3DDF90.9040306@dynamicsoft.com> References: <001101c19495$2b65bbd0$2b01a8c0@broadsoft.com> <3C3DDF90.9040306@dynamicsoft.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 10 Jan 2002 13:15:18 -0600 Message-Id: <1010690358.1914.2.camel@rocinante> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Actually, I hated it back then, too--and probably missed the argument to argue harder against it. At the risk of repeating myself, my complaint is that the client may have good reason for wanting a particular expiration. I will not speculate further on what the good reason might be, but I will be very surprised if people don't fine one. If the REGISTER transaction had an ACK where the client could say "sorry, that larger expires will not work for me". Without such a mechansim, the registrar should assume the client had a reason for choosing the expiration. If that value violates some policy of the registrar, the registrar should reject the request. It doesn't matter if the policy is "Expires must be >X" or "Expires must be an odd number", or "Expires must be not be in absolute form" or "the moon must be full." Why is this different than the complementary policy of "Expires must be <=X?" Well, one assumes that, if a client needs to increase the expiration time in the future, it will be around to do it. You cannot make the same assumption for a client needing to de-register early. On Thu, 2002-01-10 at 12:38, Jonathan Rosenberg wrote: > Brett makes some excellent points. Thanks for recapping > the old discussion. > > Based on this, I would therefore propose to keep what > we have, and allow the registrar to increase the durations, > indicating that an exception should be made for 0, and > document that this means setting registrations with > expires is not the right way to get call services. > > Let us resolve this issue finally. > > -Jonathan R. > > Brett Tate wrote: > > >>The ONLY thing solved by the increasing-duration > >>capability was to handle compliant, but > >>"overly zealous" user agents. There is no > >>disagreement that it doesn't help with dos > >>attacks. > >> > >>Perhaps the right solution, then, is to allow > >>registrars to only decrease, and to provide an > >>error response code to provide a general > >>"you're sending too fast, slow down" capability, > >>which would also be helpful for SUBSCRIBE, for > >>example, which will suffer the same problem. > >> > >>Comments? > >> > > > > All of these same points were raised last summer > > around the time we were also trying to address > > short Session-Expires. > > (Sorry, I couldn't reach > > http://lists.bell-labs.com/pipermail/sip/ > > to link the thread). > > > > At that time, the decision was that the REGISTER > > was not intend to register services like temporary > > call forwarding through the use of the expires > > header or parameter. Nobody was overly opposed > > to the backward compatibility issue with rfc2543. > > People didn't really think reallocation of a > > contact to a different subscriber would really > > be an issue. > > > > The problem with returning an error response is > > that non-bis compliant UAC's would reduce the > > response to 400. Thus it might actually produce > > more registrations and restrict the user from > > receiving calls until customer support > > communicates what the timer should be. > > > > The problem with UAS extending the timer is that > > non-bis compliant UAC might continue to register > > based upon original expires. This isn't that > > big a deal. The registrar could kick off an > > email, auto-call, or begin rejecting the REGISTER > > to ensure the situation gets corrected. > > > > Ultimately, I don't mind which solution is > > chosen, I would just like to see it closed > > for good. If a vote is required, I'd prefer > > allowing the registrar to modify the > > expires however it desires as long as it > > gets communicated back to the UAC so it knows > > when to refresh or cancel the registration. > > This would help avoid the need for user > > reconfiguration since the UAC gives the > > preference and the UAS gives the decision. > > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 15:13:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23025 for ; Thu, 10 Jan 2002 15:13:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13225 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 15:13:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12266; Thu, 10 Jan 2002 14:54:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12233 for ; Thu, 10 Jan 2002 14:54:22 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22532 for ; Thu, 10 Jan 2002 14:54:19 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0AJpxvw026915; Thu, 10 Jan 2002 14:51:59 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Jan 2002 14:53:44 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E944@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Sean Olson'" , Robert Sparks , Jonathan Rosenberg , brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time Date: Thu, 10 Jan 2002 14:53:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org It _used to be_ negotiation and it still should be! The point you miss below is being able to turn it off. By allowing a registrar to extend the registration interval, you add a burden for the endpoint to actually be around to unregister itself instead of having the state just go away. This clobbers a whole class of applications where registration and use of the registered information is highly decoupled. (3rd party registrations for example). RjS > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Thursday, January 10, 2002 1:44 PM > To: Robert Sparks; Jonathan Rosenberg; brett@broadsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] Open Issue #290: Registrar increasing registration > life time > > > But this isn't negotiation. The expiration value > defines state/service in the server. Ultimately > it is completely up to the registrar to determine > how long it will maintain state for. If the server > decides to increase the value, the only impact > to the client is that it needs to send a de-REGISTER > if it truly wants a smaller registration period. > I don't think this is significant because the client > will likely have implemented logic to handle > re-REGISTERs anyways (i.e. the client has a notion > of how long it's registration state is valid for > and is maintaining a timer of sorts to determine > when to send a re-REGISTER.) > > I strongly > agree with the notion of soft-state. I would > go further and say that registration is actually > "fuzzy" state meaning that we are not really > talking about well defined or crisp time boundaries > here. The difference between holding state for > 10 seconds or 15 seconds is not significant for > instance. And as Jonathan pointed out, services > should not depend on such crisp values. I don't > believe that having to send a de/re-REGISTER is > a violation of soft state. > > --- Robert Sparks wrote: > > I still feel strongly that the registrar should only > > shorten > > the lifetime of the registration. The spirit should > > be > > negotiation, not server assignment. With the > > registrar extending > > the expiration, there is no way for the client to > > object to > > an excessive time (requiring it to remember when it > > really > > wanted to "deregister" defeats the whole purpose of > > softstate). > > > > RjS > > > > > -----Original Message----- > > > From: Jonathan Rosenberg > > [mailto:jdrosen@dynamicsoft.com] > > > Sent: Thursday, January 10, 2002 12:38 PM > > > To: brett@broadsoft.com > > > Cc: sip@ietf.org > > > Subject: Re: [Sip] Open Issue #290: Registrar > > increasing registration > > > life time > > > > > > > > > Brett makes some excellent points. Thanks for > > recapping > > > the old discussion. > > > > > > Based on this, I would therefore propose to keep > > what > > > we have, and allow the registrar to increase the > > durations, > > > indicating that an exception should be made for 0, > > and > > > document that this means setting registrations > > with > > > expires is not the right way to get call services. > > > > > > Let us resolve this issue finally. > > > > > > -Jonathan R. > > > > > > Brett Tate wrote: > > > > > > >>The ONLY thing solved by the increasing-duration > > > > > >>capability was to handle compliant, but > > > >>"overly zealous" user agents. There is no > > > >>disagreement that it doesn't help with dos > > > >>attacks. > > > >> > > > >>Perhaps the right solution, then, is to allow > > > >>registrars to only decrease, and to provide an > > > >>error response code to provide a general > > > >>"you're sending too fast, slow down" capability, > > > > > >>which would also be helpful for SUBSCRIBE, for > > > >>example, which will suffer the same problem. > > > >> > > > >>Comments? > > > >> > > > > > > > > All of these same points were raised last summer > > > > around the time we were also trying to address > > > > short Session-Expires. > > > > (Sorry, I couldn't reach > > > > http://lists.bell-labs.com/pipermail/sip/ > > > > to link the thread). > > > > > > > > At that time, the decision was that the REGISTER > > > > was not intend to register services like > > temporary > > > > call forwarding through the use of the expires > > > > header or parameter. Nobody was overly opposed > > > > to the backward compatibility issue with > > rfc2543. > > > > People didn't really think reallocation of a > > > > contact to a different subscriber would really > > > > be an issue. > > > > > > > > The problem with returning an error response is > > > > that non-bis compliant UAC's would reduce the > > > > response to 400. Thus it might actually produce > > > > more registrations and restrict the user from > > > > receiving calls until customer support > > > > communicates what the timer should be. > > > > > > > > The problem with UAS extending the timer is that > > > > non-bis compliant UAC might continue to register > > > > based upon original expires. This isn't that > > > > big a deal. The registrar could kick off an > > > > email, auto-call, or begin rejecting the > > REGISTER > > > > to ensure the situation gets corrected. > > > > > > > > Ultimately, I don't mind which solution is > > > > chosen, I would just like to see it closed > > > > for good. If a vote is required, I'd prefer > > > > allowing the registrar to modify the > > > > expires however it desires as long as it > > > > gets communicated back to the UAC so it knows > > > > when to refresh or cancel the registration. > > > > This would help avoid the need for user > > > > reconfiguration since the UAC gives the > > > > preference and the UAS gives the decision. > > > > > > > > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 72 Eagle > > Rock Avenue > > > Chief Scientist First > > Floor > > > dynamicsoft East > > Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) > > 952-5050 > > > http://www.jdrosen.net PH: (973) > > 952-5000 > > > http://www.dynamicsoft.com > > > > > > > > > _______________________________________________ > > > Sip mailing list > > http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP > > Protocol > > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > _______________________________________________ > > Sip mailing list > > http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip > > > ===== > -- > Sean Olson > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 15:35:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23401 for ; Thu, 10 Jan 2002 15:35:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA13933 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 15:35:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13149; Thu, 10 Jan 2002 15:11:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13119 for ; Thu, 10 Jan 2002 15:11:28 -0500 (EST) Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22940 for ; Thu, 10 Jan 2002 15:11:25 -0500 (EST) Message-ID: <20020110201126.92316.qmail@web11608.mail.yahoo.com> Received: from [208.237.135.12] by web11608.mail.yahoo.com via HTTP; Thu, 10 Jan 2002 12:11:26 PST Date: Thu, 10 Jan 2002 12:11:26 -0800 (PST) From: Sean Olson Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time To: Robert Sparks , Jonathan Rosenberg , brett@broadsoft.com Cc: sip@ietf.org In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E944@DYN-TX-EXCH-001.dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org My real point is that the "Expires" value is not a hard concrete number that will necessarily be obeyed in as precise a manner as you seem to want. I understand that it may not be feasible to de-register for some applications. The real question is how much does it hurt to have that (soft)state in the network? How critical is it to your service that the registrar purge the state at that time? /sean --- Robert Sparks wrote: > It _used to be_ negotiation and it still should be! > > The point you miss below is being able to turn it > off. > By allowing a registrar to extend the registration > interval, > you add a burden for the endpoint to actually be > around to > unregister itself instead of having the state just > go away. > This clobbers a whole class of applications where > registration > and use of the registered information is highly > decoupled. > (3rd party registrations for example). > > RjS > > > -----Original Message----- > > From: Sean Olson [mailto:seancolson@yahoo.com] > > Sent: Thursday, January 10, 2002 1:44 PM > > To: Robert Sparks; Jonathan Rosenberg; > brett@broadsoft.com > > Cc: sip@ietf.org > > Subject: RE: [Sip] Open Issue #290: Registrar > increasing registration > > life time > > > > > > But this isn't negotiation. The expiration value > > defines state/service in the server. Ultimately > > it is completely up to the registrar to determine > > how long it will maintain state for. If the server > > decides to increase the value, the only impact > > to the client is that it needs to send a > de-REGISTER > > if it truly wants a smaller registration period. > > I don't think this is significant because the > client > > will likely have implemented logic to handle > > re-REGISTERs anyways (i.e. the client has a notion > > of how long it's registration state is valid for > > and is maintaining a timer of sorts to determine > > when to send a re-REGISTER.) > > > > I strongly > > agree with the notion of soft-state. I would > > go further and say that registration is actually > > "fuzzy" state meaning that we are not really > > talking about well defined or crisp time > boundaries > > here. The difference between holding state for > > 10 seconds or 15 seconds is not significant for > > instance. And as Jonathan pointed out, services > > should not depend on such crisp values. I don't > > believe that having to send a de/re-REGISTER is > > a violation of soft state. > > > > --- Robert Sparks wrote: > > > I still feel strongly that the registrar should > only > > > shorten > > > the lifetime of the registration. The spirit > should > > > be > > > negotiation, not server assignment. With the > > > registrar extending > > > the expiration, there is no way for the client > to > > > object to > > > an excessive time (requiring it to remember when > it > > > really > > > wanted to "deregister" defeats the whole purpose > of > > > softstate). > > > > > > RjS > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg > > > [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Thursday, January 10, 2002 12:38 PM > > > > To: brett@broadsoft.com > > > > Cc: sip@ietf.org > > > > Subject: Re: [Sip] Open Issue #290: Registrar > > > increasing registration > > > > life time > > > > > > > > > > > > Brett makes some excellent points. Thanks for > > > recapping > > > > the old discussion. > > > > > > > > Based on this, I would therefore propose to > keep > > > what > > > > we have, and allow the registrar to increase > the > > > durations, > > > > indicating that an exception should be made > for 0, > > > and > > > > document that this means setting registrations > > > with > > > > expires is not the right way to get call > services. > > > > > > > > Let us resolve this issue finally. > > > > > > > > -Jonathan R. > > > > > > > > Brett Tate wrote: > > > > > > > > >>The ONLY thing solved by the > increasing-duration > > > > > > > >>capability was to handle compliant, but > > > > >>"overly zealous" user agents. There is no > > > > >>disagreement that it doesn't help with dos > > > > >>attacks. > > > > >> > > > > >>Perhaps the right solution, then, is to > allow > > > > >>registrars to only decrease, and to provide > an > > > > >>error response code to provide a general > > > > >>"you're sending too fast, slow down" > capability, > > > > > > > >>which would also be helpful for SUBSCRIBE, > for > > > > >>example, which will suffer the same problem. > > > > >> > > > > >>Comments? > > > > >> > > > > > > > > > > All of these same points were raised last > summer > > > > > around the time we were also trying to > address > > > > > short Session-Expires. > > > > > (Sorry, I couldn't reach > > > > > http://lists.bell-labs.com/pipermail/sip/ > > > > > to link the thread). > > > > > > > > > > At that time, the decision was that the > REGISTER > > > > > was not intend to register services like > > > temporary > > > > > call forwarding through the use of the > expires > > > > > header or parameter. Nobody was overly > opposed > > > > > to the backward compatibility issue with > > > rfc2543. > > > > > People didn't really think reallocation of a > > > > > contact to a different subscriber would > really > > > > > be an issue. > > > > > > > > > > The problem with returning an error response > is > > > > > that non-bis compliant UAC's would reduce > the > > > > > response to 400. Thus it might actually > produce > > > > > more registrations and restrict the user > from > > > > > receiving calls until customer support > > > > > communicates what the timer should be. > > > > > > > > > > The problem with UAS extending the timer is > that > > > > > non-bis compliant UAC might continue to > register > > > > > based upon original expires. This isn't > that > > > > > big a deal. The registrar could kick off an > > > > > email, auto-call, or begin rejecting the > > > REGISTER > > > > > to ensure the situation gets corrected. > > > > > > > > > > Ultimately, I don't mind which solution is > > > > > chosen, I would just like to see it closed > > > > > for good. If a vote is required, I'd prefer > > > > > allowing the registrar to modify the > > > > > expires however it desires as long as it > > > > > gets communicated back to the UAC so it > knows > > > > > when to refresh or cancel the registration. > > > > > This would help avoid the need for user > > > > > reconfiguration since the UAC gives the > > > > > preference and the UAS gives the decision. > > > > > > > > > > > > > > > > > > > > > > -- > > > > Jonathan D. Rosenberg, Ph.D. 72 > Eagle > === message truncated === ===== -- Sean Olson __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 16:22:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24095 for ; Thu, 10 Jan 2002 16:22:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15210 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 16:22:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14318; Thu, 10 Jan 2002 15:56:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14211 for ; Thu, 10 Jan 2002 15:55:58 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23703 for ; Thu, 10 Jan 2002 15:55:52 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0AKrNvw027690; Thu, 10 Jan 2002 15:53:23 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 15:55:08 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E947@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Sean Olson'" , Robert Sparks , Jonathan Rosenberg , brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time Date: Thu, 10 Jan 2002 15:54:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Thursday, January 10, 2002 2:11 PM > To: Robert Sparks; Jonathan Rosenberg; brett@broadsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] Open Issue #290: Registrar increasing registration > life time > > > My real point is that the "Expires" value > is not a hard concrete number that will > necessarily be obeyed in as precise a manner > as you seem to want. I understand that it may > not be feasible to de-register for some applications. > > The real question is how much does it hurt to have > that (soft)state in the network? How critical > is it to your service that the registrar purge > the state at that time? Potentially alot. (yes, I know the removal time will be fuzzy, but if I ask for an hour, having stuff stay around for a week will break things). > > /sean > > --- Robert Sparks wrote: > > It _used to be_ negotiation and it still should be! > > > > The point you miss below is being able to turn it > > off. > > By allowing a registrar to extend the registration > > interval, > > you add a burden for the endpoint to actually be > > around to > > unregister itself instead of having the state just > > go away. > > This clobbers a whole class of applications where > > registration > > and use of the registered information is highly > > decoupled. > > (3rd party registrations for example). > > > > RjS > > > > > -----Original Message----- > > > From: Sean Olson [mailto:seancolson@yahoo.com] > > > Sent: Thursday, January 10, 2002 1:44 PM > > > To: Robert Sparks; Jonathan Rosenberg; > > brett@broadsoft.com > > > Cc: sip@ietf.org > > > Subject: RE: [Sip] Open Issue #290: Registrar > > increasing registration > > > life time > > > > > > > > > But this isn't negotiation. The expiration value > > > defines state/service in the server. Ultimately > > > it is completely up to the registrar to determine > > > how long it will maintain state for. If the server > > > decides to increase the value, the only impact > > > to the client is that it needs to send a > > de-REGISTER > > > if it truly wants a smaller registration period. > > > I don't think this is significant because the > > client > > > will likely have implemented logic to handle > > > re-REGISTERs anyways (i.e. the client has a notion > > > of how long it's registration state is valid for > > > and is maintaining a timer of sorts to determine > > > when to send a re-REGISTER.) > > > > > > I strongly > > > agree with the notion of soft-state. I would > > > go further and say that registration is actually > > > "fuzzy" state meaning that we are not really > > > talking about well defined or crisp time > > boundaries > > > here. The difference between holding state for > > > 10 seconds or 15 seconds is not significant for > > > instance. And as Jonathan pointed out, services > > > should not depend on such crisp values. I don't > > > believe that having to send a de/re-REGISTER is > > > a violation of soft state. > > > > > > --- Robert Sparks wrote: > > > > I still feel strongly that the registrar should > > only > > > > shorten > > > > the lifetime of the registration. The spirit > > should > > > > be > > > > negotiation, not server assignment. With the > > > > registrar extending > > > > the expiration, there is no way for the client > > to > > > > object to > > > > an excessive time (requiring it to remember when > > it > > > > really > > > > wanted to "deregister" defeats the whole purpose > > of > > > > softstate). > > > > > > > > RjS > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg > > > > [mailto:jdrosen@dynamicsoft.com] > > > > > Sent: Thursday, January 10, 2002 12:38 PM > > > > > To: brett@broadsoft.com > > > > > Cc: sip@ietf.org > > > > > Subject: Re: [Sip] Open Issue #290: Registrar > > > > increasing registration > > > > > life time > > > > > > > > > > > > > > > Brett makes some excellent points. Thanks for > > > > recapping > > > > > the old discussion. > > > > > > > > > > Based on this, I would therefore propose to > > keep > > > > what > > > > > we have, and allow the registrar to increase > > the > > > > durations, > > > > > indicating that an exception should be made > > for 0, > > > > and > > > > > document that this means setting registrations > > > > with > > > > > expires is not the right way to get call > > services. > > > > > > > > > > Let us resolve this issue finally. > > > > > > > > > > -Jonathan R. > > > > > > > > > > Brett Tate wrote: > > > > > > > > > > >>The ONLY thing solved by the > > increasing-duration > > > > > > > > > >>capability was to handle compliant, but > > > > > >>"overly zealous" user agents. There is no > > > > > >>disagreement that it doesn't help with dos > > > > > >>attacks. > > > > > >> > > > > > >>Perhaps the right solution, then, is to > > allow > > > > > >>registrars to only decrease, and to provide > > an > > > > > >>error response code to provide a general > > > > > >>"you're sending too fast, slow down" > > capability, > > > > > > > > > >>which would also be helpful for SUBSCRIBE, > > for > > > > > >>example, which will suffer the same problem. > > > > > >> > > > > > >>Comments? > > > > > >> > > > > > > > > > > > > All of these same points were raised last > > summer > > > > > > around the time we were also trying to > > address > > > > > > short Session-Expires. > > > > > > (Sorry, I couldn't reach > > > > > > http://lists.bell-labs.com/pipermail/sip/ > > > > > > to link the thread). > > > > > > > > > > > > At that time, the decision was that the > > REGISTER > > > > > > was not intend to register services like > > > > temporary > > > > > > call forwarding through the use of the > > expires > > > > > > header or parameter. Nobody was overly > > opposed > > > > > > to the backward compatibility issue with > > > > rfc2543. > > > > > > People didn't really think reallocation of a > > > > > > contact to a different subscriber would > > really > > > > > > be an issue. > > > > > > > > > > > > The problem with returning an error response > > is > > > > > > that non-bis compliant UAC's would reduce > > the > > > > > > response to 400. Thus it might actually > > produce > > > > > > more registrations and restrict the user > > from > > > > > > receiving calls until customer support > > > > > > communicates what the timer should be. > > > > > > > > > > > > The problem with UAS extending the timer is > > that > > > > > > non-bis compliant UAC might continue to > > register > > > > > > based upon original expires. This isn't > > that > > > > > > big a deal. The registrar could kick off an > > > > > > email, auto-call, or begin rejecting the > > > > REGISTER > > > > > > to ensure the situation gets corrected. > > > > > > > > > > > > Ultimately, I don't mind which solution is > > > > > > chosen, I would just like to see it closed > > > > > > for good. If a vote is required, I'd prefer > > > > > > allowing the registrar to modify the > > > > > > expires however it desires as long as it > > > > > > gets communicated back to the UAC so it > > knows > > > > > > when to refresh or cancel the registration. > > > > > > This would help avoid the need for user > > > > > > reconfiguration since the UAC gives the > > > > > > preference and the UAS gives the decision. > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg, Ph.D. 72 > > Eagle > > > === message truncated === > > > ===== > -- > Sean Olson > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 16:41:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24387 for ; Thu, 10 Jan 2002 16:41:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15998 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 16:41:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15171; Thu, 10 Jan 2002 16:21:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15145 for ; Thu, 10 Jan 2002 16:21:05 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24088 for ; Thu, 10 Jan 2002 16:21:03 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0ALKwVZ012600; Thu, 10 Jan 2002 16:21:00 -0500 (EST) Message-ID: <3C3E0599.4050806@dynamicsoft.com> Date: Thu, 10 Jan 2002 16:20:25 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Sparks CC: "'Sean Olson'" , brett@broadsoft.com, sip@ietf.org Subject: Re: [Sip] Open Issue #290: Registrar increasing registration life time References: <9BF66EBF6BEFD942915B4D4D45C051F338E947@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert Sparks wrote: > >>My real point is that the "Expires" value >>is not a hard concrete number that will >>necessarily be obeyed in as precise a manner >>as you seem to want. I understand that it may >>not be feasible to de-register for some applications. >> >>The real question is how much does it hurt to have >>that (soft)state in the network? How critical >>is it to your service that the registrar purge >>the state at that time? >> > > Potentially alot. (yes, I know the removal time > will be fuzzy, but if I ask for an hour, > having stuff stay around for a week will > break things). I don't feel all that strongly here, as I see points on both sides. I think much of the issue depends on whether or not registration times are really used to drive services or not. Robert, I would ask that more specific examples be provided to assist in resolving the issue. Also, I'd welcome thoughts on some of the other points Brett raised, specifically, the fact that there is a backwards compatibility issue with sending an error response if the interval is too short. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 16:45:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24448 for ; Thu, 10 Jan 2002 16:45:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16030 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 16:45:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15296; Thu, 10 Jan 2002 16:25:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15265 for ; Thu, 10 Jan 2002 16:25:38 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24140 for ; Thu, 10 Jan 2002 16:25:37 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0ALP8F16165; Thu, 10 Jan 2002 13:25:08 -0800 (PST) Received: from cisco.com (eckelcu-lnx.cisco.com [128.107.140.110]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ABT92338; Thu, 10 Jan 2002 13:25:15 -0800 (PST) Message-ID: <3C3E06B3.F37D979F@cisco.com> Date: Thu, 10 Jan 2002 13:25:07 -0800 From: Charles Eckel Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-23.uid32 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Shail Bhatnagar , Brian Stucker , Scott Orton , "'Kiranmai Pavoori'" , vkg , sip Subject: Re: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! References: <3C38FBEB.96DE1980@cisco.com> <3C3DE79B.5090201@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Maybe its a small point, but if fallback values are going to be specified, it may be of value to state a context sensitive fallback value. For a contact, I agree that 3600 is reasonable; however, for an INVITE a value of 180 seems more appropriate. I thought these were the default to assume in case of the absence of any Expires header for the respective cases, but I don't see any mention of such defaults in bis-05. Just my 2 cents. Cheers -- Charles Eckel Software Engineer Voice Technology Group, Cisco Systems http://www.cisco.com Jonathan Rosenberg wrote: > > OK, great to hear! > > Well then, it looks like we can indeed go full steam ahead, and totally > remove absolute times in Expires from the specification. > > I would like to do that as well for Retry-After, I assume if people are > OK with this for Expires it will be OK for Retry-After. > > Most likely I will also add text that says "if you see a malformed value > in the expires header or param (which an absolute time would be), assume > a value of 3600. This assures that things would still even work, albeit > not quite right, if someone still had an old registrar around that was > sending absolute times. > > Thanks, > Jonathan R. > > Charles Eckel wrote: > > > Jonathan, > > > > We can/will make the necessary modifications to comply with the > > depreciation, so you have the green light from Cisco. > > Shail, thanks for clarifying the issue and the necessary fix. > > > > Cheers > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 10 20:26:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27243 for ; Thu, 10 Jan 2002 20:26:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA22326 for sip-archive@odin.ietf.org; Thu, 10 Jan 2002 20:26:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22079; Thu, 10 Jan 2002 20:07:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22048 for ; Thu, 10 Jan 2002 20:07:06 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27011 for ; Thu, 10 Jan 2002 20:07:04 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0B175b11834 for ; Thu, 10 Jan 2002 19:07:05 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Jan 2002 19:07:05 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAADB9@va02.va.neustar.com> From: "Peterson, Jon" To: "'sip@ietf.org'" Date: Thu, 10 Jan 2002 19:07:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Bug #113 Overlapping transactions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Please note that I'm speaking below to the issue of overlapping concurrent transactions in SIP, NOT to the issue of handling partial dialed numbers in the PSTN, which is commonly referred to as overlap signaling. There didn't seem to be very much controversy in the recent bug #113 thread about allowing overlapping non-INVITE transactions. The general feeling is that we want to leave the door open for non-INVITE methods to overlap provided that they define their own ordering mechanisms as necessary. There was a bit more discussion on the subject of whether or not overlapping INVITE transactions should be allowed. It has been pointed out that allowing overlapping INVITEs would introduce some backwards compatibility problems. In past discussion, probably the single most important motivation for overlapping INVITEs has been the proposed early media mechanism. Some support was raised for a proposed UPDATE or OFFER method that would present an alternative to sending an overlapping INVITE during an early dialog. No strenuous objections were raised to this line of inquiry. I understand that there are now some people looking at putting out a proposal along these lines that should be available shortly. Since we need to wrap this up if at all possible for bis-06, I'd like to suggest that we do the following: Disallow overlapping INVITE transactions in the baseline spec with the understanding that an extension (along the lines of UPDATE or OFFER) could provide the necessary functionality for early media or other services that need to modify a session during the early dialog stage. Allow overlapping non-INVITE. Is this okay with everyone? Please do speak up if this isn't okay with you. Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 11 00:05:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01876 for ; Fri, 11 Jan 2002 00:05:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA07184 for sip-archive@odin.ietf.org; Fri, 11 Jan 2002 00:05:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06546; Thu, 10 Jan 2002 23:46:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06515 for ; Thu, 10 Jan 2002 23:46:04 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01657 for ; Thu, 10 Jan 2002 23:46:02 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0B4hlvw000283 for ; Thu, 10 Jan 2002 23:43:48 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Jan 2002 23:45:33 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E955@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Thu, 10 Jan 2002 23:45:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Loose Routing draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I just submitted a draft refining the post I sent out after IETF52 on the loose routing proposal. Until it appears in the archive, you can find it at http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt or http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html RjS _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 11 01:59:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03013 for ; Fri, 11 Jan 2002 01:59:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA18489 for sip-archive@odin.ietf.org; Fri, 11 Jan 2002 01:59:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18152; Fri, 11 Jan 2002 01:41:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA18123 for ; Fri, 11 Jan 2002 01:40:57 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02884 for ; Fri, 11 Jan 2002 01:40:55 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0B6eoJ14458; Fri, 11 Jan 2002 07:40:51 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.14]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0B6eohO028916; Fri, 11 Jan 2002 08:40:50 +0200 (EET) Message-ID: <3C3E88BE.B606E5D9@lmf.ericsson.se> Date: Fri, 11 Jan 2002 08:39:58 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John.Hearty@Level3.com CC: jdrosen@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] Open Issue #207: Handling of session failures References: <17052388D394D411803900508BDFFAF601B37126@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Now, THIS is a good point. >> >>A network failure, could trigger a storm of INVITEs which might only >>make the situation worse. >> >>OK, I am willing to concede that use of the mecahnism when you don't >>know that it is the endpoint that failed, could be quite bad. >> >>So, since: >> >>(1) it could actually hurt alot >It is not clear to me this would hurt alot. The extra SIP messages are >likely to be insignificant compared to all the RTP and ICMPs bouncing >around. I'll conceed they may not be going exactly the same place, so some >network segments could get pounded that previously saw little traffic. Yes, and especially if the control- and media nodes are separated (eg using H.248/MGCP) the SIP signalling and RTP media will most likely use different paths. I DO agree (I've said it myself in the UDP vs TCP discussion) that the signalling traffic (number of IP packets) is pretty small compared to the media traffic, but why make things worse? Also, the signalling traffic also affects intermediate SIP nodes, which we don't want to overload unless necessary (eg a proxy could suddenly get tens of thousands of re-INVITEs from a gateway, and as many re-INVITEs from the endnodes talking to that gateway, and none of these re-INVITEs will do any good since the error is in the IP network...). I think, and agree with Jonathan, that this should be done based on local policy. That, however, doesn't mean we don't have to say a word about it. But, as proposed it should be done within an extension (by defining a new SIP extension or simply by making a BCP document) outside the scope of bis. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 11 07:27:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13578 for ; Fri, 11 Jan 2002 07:27:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA27430 for sip-archive@odin.ietf.org; Fri, 11 Jan 2002 07:27:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26524; Fri, 11 Jan 2002 06:58:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26494 for ; Fri, 11 Jan 2002 06:58:13 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13379 for ; Fri, 11 Jan 2002 06:58:11 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id LAA29844; Fri, 11 Jan 2002 11:52:27 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id LAA17227; Fri, 11 Jan 2002 11:58:06 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 04:58:01 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B37128@n0214idc1.oss.level3.com> To: christer.holmberg@lmf.ericsson.se Cc: jdrosen@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] Open Issue #207: Handling of session failures Date: Fri, 11 Jan 2002 04:58:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Agreed. All good points. Lets wrap this one up. > Hi, > > >>Now, THIS is a good point. > >> > >>A network failure, could trigger a storm of INVITEs which might only > >>make the situation worse. > >> > >>OK, I am willing to concede that use of the mecahnism when you don't > >>know that it is the endpoint that failed, could be quite bad. > >> > >>So, since: > >> > >>(1) it could actually hurt alot > >It is not clear to me this would hurt alot. The extra SIP > messages are > >likely to be insignificant compared to all the RTP and ICMPs bouncing > >around. I'll conceed they may not be going exactly the same > place, so some > >network segments could get pounded that previously saw > little traffic. > > Yes, and especially if the control- and media nodes are separated (eg > using H.248/MGCP) the SIP signalling and RTP media will most > likely use > different paths. > > I DO agree (I've said it myself in the UDP vs TCP discussion) that the > signalling traffic (number of IP packets) is pretty small compared to > the media traffic, but why make things worse? > > Also, the signalling traffic also affects intermediate SIP > nodes, which > we don't want to overload unless necessary (eg a proxy could suddenly > get tens of thousands of re-INVITEs from a gateway, and as many > re-INVITEs from the endnodes talking to that gateway, and > none of these > re-INVITEs will do any good since the error is in the IP network...). > > I think, and agree with Jonathan, that this should be done based on > local policy. That, however, doesn't mean we don't have to say a word > about it. But, as proposed it should be done within an extension (by > defining a new SIP extension or simply by making a BCP > document) outside > the scope of bis. > > Regards, > > Christer Holmberg > Ericsson Finland > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 11 09:21:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15576 for ; Fri, 11 Jan 2002 09:21:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA00720 for sip-archive@odin.ietf.org; Fri, 11 Jan 2002 09:21:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29978; Fri, 11 Jan 2002 08:55:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29950 for ; Fri, 11 Jan 2002 08:55:08 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14507 for ; Fri, 11 Jan 2002 08:55:01 -0500 (EST) From: bernhard.honeisen@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0BDsou21160 for ; Fri, 11 Jan 2002 15:54:51 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Jan 2002 15:55:02 +0200 Received: by esebh03nok with Internet Mail Service (5.5.2652.78) id ; Fri, 11 Jan 2002 15:55:02 +0200 Message-ID: To: rsparks@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] Loose Routing draft Date: Fri, 11 Jan 2002 15:54:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Robert et al.! Intersting I/D! It looks like, that we have a solution for the problem. I have a couple of questions/comments: I assume this new procedure can be applied for initial and subsequent requests. Is this assumention correct? Is there a requirement, that loose routing is needed in subsequent requests? What would be the impact, if we allow a local policy (as described in your I/D) for the INITIAL request ONLY, and leave subsequent requests as before (i.e. strict source routing). Or in other words: Apply this local policy for pre-loaded route headers only. Therefore we could introduce a new Route parameter, which informs about, that the Routing can be loose, or has to be strict. e.g. Route: proxyA@networkB.com; routing=loose (or similar) New proxy implementations would route strict, if no such paramenter present and apply the local policy only of this parameter present. Older proxy implementations would simply ignore this new parameter. I see the following advantages of my proposal: - Changes to existing SIP are fewer (only the new case of pre-loaded route headers in initial request would be affected) - more backwards compatibility - Less new error cases (can apear only during session first INVITE) - Pre-loaded Route headers can be defined as "loose" or as "strict" I am looking forward for comments on this proposal! cheers, Bernie >-----Original Message----- >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: 11. January 2002 6:46 >To: sip@ietf.org >Subject: [Sip] Loose Routing draft > > >I just submitted a draft refining the post I sent >out after IETF52 on the loose routing proposal. > >Until it appears in the archive, you can find it at >http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt >or >http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html > > >RjS > >_______________________________________________ >Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 11 10:19:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17306 for ; Fri, 11 Jan 2002 10:19:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02381 for sip-archive@odin.ietf.org; Fri, 11 Jan 2002 10:19:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01672; Fri, 11 Jan 2002 09:58:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01641 for ; Fri, 11 Jan 2002 09:58:01 -0500 (EST) Received: from web11605.mail.yahoo.com (web11605.mail.yahoo.com [216.136.172.57]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16460 for ; Fri, 11 Jan 2002 09:57:58 -0500 (EST) Message-ID: <20020111145800.75101.qmail@web11605.mail.yahoo.com> Received: from [216.51.102.77] by web11605.mail.yahoo.com via HTTP; Fri, 11 Jan 2002 06:58:00 PST Date: Fri, 11 Jan 2002 06:58:00 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Bug #113 Overlapping transactions To: "Peterson, Jon" , "'sip@ietf.org'" In-Reply-To: <70565611B164D511957A001083FCDD56CAADB9@va02.va.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I would like to know the objections to overlapping INVITEs that wouldn't also apply to overlapping non-INVITEs. I personally favor an overlapping INVITE for solving early media over any new UPDATE or OFFER methods. It just seems much more straightforward in my mind. Are there large technical hurdles to overlapping INVITE transactions that I am not seeing? BR, sean > Since we need to wrap this up if at all possible for > bis-06, I'd like to > suggest that we do the following: > > Disallow overlapping INVITE transactions in the > baseline spec with the > understanding that an extension (along the lines of > UPDATE or OFFER) could > provide the necessary functionality for early media > or other services that > need to modify a session during the early dialog > stage. > > Allow overlapping non-INVITE. > > Is this okay with everyone? Please do speak up if > this isn't okay with you. > > Jon Peterson > NeuStar, Inc. ===== -- Sean Olson __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 11 10:21:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17401 for ; Fri, 11 Jan 2002 10:21:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02417 for sip-archive@odin.ietf.org; Fri, 11 Jan 2002 10:21:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01576; Fri, 11 Jan 2002 09:55:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01547 for ; Fri, 11 Jan 2002 09:55:01 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16368 for ; Fri, 11 Jan 2002 09:54:59 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0BEqdvw002275; Fri, 11 Jan 2002 09:52:40 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Jan 2002 09:54:22 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E95A@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'bernhard.honeisen@nokia.com'" , Robert Sparks , sip@ietf.org Subject: RE: [Sip] Loose Routing draft Date: Fri, 11 Jan 2002 09:54:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: bernhard.honeisen@nokia.com [mailto:bernhard.honeisen@nokia.com] > Sent: Friday, January 11, 2002 7:54 AM > To: rsparks@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] Loose Routing draft > > > Hi Robert et al.! > > Intersting I/D! It looks like, that we have a solution > for the problem. > > I have a couple of questions/comments: > > I assume this new procedure can be applied for initial and > subsequent requests. Is this assumention correct? Yes it can. Note that different policies can be applied to initial and subsequent requests (so you could loose-route the initial and strict-route subsequents if that's what you wanted to do). > > Is there a requirement, that loose routing is needed in > subsequent requests? There are people that want to be able to do this. > > What would be the impact, if we allow a local policy > (as described in your I/D) for the INITIAL request ONLY, > and leave subsequent requests as before (i.e. strict > source routing). > Or in other words: Apply this local policy for > pre-loaded route headers only. We don't preclude that policy but I don't believe we should require it. > > Therefore we could introduce a new Route parameter, which > informs about, that the Routing can be loose, or has > to be strict. > > e.g. Route: proxyA@networkB.com; routing=loose > (or similar) There's a problem with who knows when to include such an indicator. If you are an endpoint, you don't know what the service you are trying to use might need to do (unless the service has told you through some mechanism like PATH, in which case the service can manage its own policy) > > New proxy implementations would route strict, if no > such paramenter present and apply the local policy > only of this parameter present. > Older proxy implementations would simply ignore this > new parameter. > > I see the following advantages of my proposal: > > - Changes to existing SIP are fewer > (only the new case of pre-loaded route headers > in initial request would be affected) > - more backwards compatibility > - Less new error cases (can apear only during session > first INVITE) > > - Pre-loaded Route headers can be defined as > "loose" or as "strict" > > > I am looking forward for comments on this proposal! > > cheers, > Bernie > > > >-----Original Message----- > >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > >Sent: 11. January 2002 6:46 > >To: sip@ietf.org > >Subject: [Sip] Loose Routing draft > > > > > >I just submitted a draft refining the post I sent > >out after IETF52 on the loose routing proposal. > > > >Until it appears in the archive, you can find it at > >http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt > >or > >http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html > > > > > >RjS > > > >_______________________________________________ > >Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 11 11:02:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19191 for ; Fri, 11 Jan 2002 11:02:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04273 for sip-archive@odin.ietf.org; Fri, 11 Jan 2002 11:02:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02557; Fri, 11 Jan 2002 10:27:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02524 for ; Fri, 11 Jan 2002 10:27:28 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17603 for ; Fri, 11 Jan 2002 10:27:25 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0BFRRb26582; Fri, 11 Jan 2002 09:27:27 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Fri, 11 Jan 2002 09:27:27 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAADBB@va02.va.neustar.com> From: "Peterson, Jon" To: "'Sean Olson'" , "'sip@ietf.org'" Subject: RE: [Sip] Bug #113 Overlapping transactions Date: Fri, 11 Jan 2002 09:27:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org There was at least one case (that of a proxy server implementing a call-forward-on-no-answer service without Record-Route) that would be broken if we allowed these overlapping INVITEs - on those grounds, the case has been made that allowing overlapping INVITEs breaks backwards compatibility with 2543. There are also concerns about what happens if the UAS gets overlapped INVITEs out of sequence and delivers hetergenous responses (like a 4xx followed by a 2xx) that, due to CSeq, have to be interpreted in reverse order by the UAC - it has been argued that the state of the call becomes kinda murky. I don't really think either of these are directly applicable to any of the non-INVITE methods we've defined today, especially given our proviso that non-INVITE methods would have to define some sort of custom ordering mechanism if ordering were necessary. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Friday, January 11, 2002 6:58 AM > To: Peterson, Jon; 'sip@ietf.org' > Subject: Re: [Sip] Bug #113 Overlapping transactions > > > I would like to know the objections to overlapping > INVITEs that wouldn't also apply to overlapping > non-INVITEs. I personally favor an overlapping > INVITE for solving early media over any new UPDATE > or OFFER methods. It just seems much more > straightforward in my mind. Are there large > technical hurdles to overlapping INVITE transactions > that I am not seeing? > > BR, > sean > > > Since we need to wrap this up if at all possible for > > bis-06, I'd like to > > suggest that we do the following: > > > > Disallow overlapping INVITE transactions in the > > baseline spec with the > > understanding that an extension (along the lines of > > UPDATE or OFFER) could > > provide the necessary functionality for early media > > or other services that > > need to modify a session during the early dialog > > stage. > > > > Allow overlapping non-INVITE. > > > > Is this okay with everyone? Please do speak up if > > this isn't okay with you. > > > > Jon Peterson > > NeuStar, Inc. > > > ===== > -- > Sean Olson > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 11 11:36:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20649 for ; Fri, 11 Jan 2002 11:36:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05805 for sip-archive@odin.ietf.org; Fri, 11 Jan 2002 11:36:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03706; Fri, 11 Jan 2002 10:56:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03675 for ; Fri, 11 Jan 2002 10:56:47 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18873 for ; Fri, 11 Jan 2002 10:56:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0BFudVZ013554; Fri, 11 Jan 2002 10:56:39 -0500 (EST) Message-ID: <3C3F0B17.1000602@dynamicsoft.com> Date: Fri, 11 Jan 2002 10:56:07 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Sean Olson CC: "Peterson, Jon" , "'sip@ietf.org'" Subject: Re: [Sip] Bug #113 Overlapping transactions References: <20020111145800.75101.qmail@web11605.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sean Olson wrote: > I would like to know the objections to overlapping > INVITEs that wouldn't also apply to overlapping > non-INVITEs. I personally favor an overlapping > INVITE for solving early media over any new UPDATE > or OFFER methods. It just seems much more > straightforward in my mind. Are there large > technical hurdles to overlapping INVITE transactions > that I am not seeing? Good question. INVITE has the unfortunate problem that it does TWO things - it manipulates session state, and it manipulates dialog state. Now, this new UPDATE mechanism would have the important property that it only updates the session state, not dialog state. SO, you can't have overlapping UPDATEs either, but an UPDATE can overlap with INVITE, since the protracted INVITE transaction exists primarily because of the duration involved in querying the user to manipulate dialog state. Note also that services in the network are driven off of dialog state, not session state, so UPDATE processing would not confuse proxies and other things, as an overlapping INVITE would. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 13 15:44:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15026 for ; Sun, 13 Jan 2002 15:44:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04790 for sip-archive@odin.ietf.org; Sun, 13 Jan 2002 15:44:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04062; Sun, 13 Jan 2002 15:15:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04031 for ; Sun, 13 Jan 2002 15:15:26 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14783 for ; Sun, 13 Jan 2002 15:15:21 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.96]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0DKFLGe014761 for ; Sun, 13 Jan 2002 15:15:21 -0500 (EST) Message-ID: <3C41EAB8.6060705@dynamicsoft.com> Date: Sun, 13 Jan 2002 15:14:48 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] testing - please ignore Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 12:37:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08788 for ; Mon, 14 Jan 2002 12:37:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA16141 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 12:37:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14998; Mon, 14 Jan 2002 12:09:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14966 for ; Mon, 14 Jan 2002 12:09:15 -0500 (EST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07321 for ; Mon, 14 Jan 2002 12:09:11 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Mon, 14 Jan 2002 09:08:43 -0800 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 14 Jan 2002 09:08:43 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Jan 2002 09:08:43 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 14 Jan 2002 09:08:43 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 14 Jan 2002 09:06:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [SIP] Use of Branch parameter within Via headers Date: Mon, 14 Jan 2002 09:06:39 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10312AB4F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [SIP] Use of Branch parameter within Via headers Thread-Index: AcGdHh5Y79fO2kE6Qpq/qdfMZ8FMxA== From: "Robert Osborne" To: X-OriginalArrivalTime: 14 Jan 2002 17:06:40.0129 (UTC) FILETIME=[D54CFF10:01C19D1D] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19D1D.D51E062D" ------_=_NextPart_001_01C19D1D.D51E062D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Within RFC 2543 section 6.40.5, is the following paragraph: =20 The "branch" parameter is included by every forking proxy. The token MUST be unique for each distinct request generated when a proxy forks. CANCEL requests MUST have the same branch value as the corresponding forked request. When a response arrives at the proxy it can use the branch value to figure out which branch the response corresponds to. A proxy which generates a single request (non- forking) MAY also insert the "branch" parameter. The identifier has to be unique only within a set of isomorphic requests. =20 From this text, all forking proxies should include the "branch" parameter.=20 However I was wondering, even though it is a "MAY" for non forking proxies=20 to insert this parameter, is there any that do? =20 Rob O =20 ------_=_NextPart_001_01C19D1D.D51E062D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi,
 
Within =
RFC 2543 section 6.40.5, is the following =
paragraph:
 
   The "branch" parameter =
is included by every forking proxy.  The =
token
   MUST be unique for each distinct =
request generated when a proxy
   forks. CANCEL requests MUST have =
the same branch value as the
   corresponding forked request. =
When a response arrives at the proxy it
   can use the branch value to =
figure out which branch the response
   corresponds to. A proxy which =
generates a single request (non-
   forking) MAY also insert the =
"branch" parameter. The identifier =
has
   to be unique only within a set =
of isomorphic requests.
 
From this =
text, all forking proxies should include the “branch” =
parameter. 
However I =
was wondering, even though it is a “MAY” for non forking =
proxies 
to insert =
this parameter, is there any that do?
 
Rob =
O

 

=00 ------_=_NextPart_001_01C19D1D.D51E062D-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 14:19:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13956 for ; Mon, 14 Jan 2002 14:19:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20747 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 14:19:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19715; Mon, 14 Jan 2002 13:58:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19684 for ; Mon, 14 Jan 2002 13:58:25 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12821 for ; Mon, 14 Jan 2002 13:58:23 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0EIu6kN003987 for ; Mon, 14 Jan 2002 13:56:06 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 14 Jan 2002 13:57:54 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E982@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Mon, 14 Jan 2002 13:57:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Attention - comment on Loose Routing draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The draft below contains the resolution to a large set of open issues around processing of the Route header, preloaded routes, and the use of default outbound proxies. The plan is to modify bis to reflect these proposals. Please review it as soon as you can and comment if you see real problems. Silence will be taken as consent. RjS > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Thursday, January 10, 2002 10:46 PM > To: 'sip@ietf.org' > Subject: [Sip] Loose Routing draft > > > I just submitted a draft refining the post I sent > out after IETF52 on the loose routing proposal. > > Until it appears in the archive, you can find it at > http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt > or > http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html > > > RjS > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 14:50:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15610 for ; Mon, 14 Jan 2002 14:50:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21768 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 14:50:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20917; Mon, 14 Jan 2002 14:25:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20885 for ; Mon, 14 Jan 2002 14:25:55 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14431 for ; Mon, 14 Jan 2002 14:25:52 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0EJNSkN004375; Mon, 14 Jan 2002 14:23:28 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 14:25:16 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E983@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , Robert Sparks Cc: "'Sean Olson'" , brett@broadsoft.com, sip@ietf.org Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time Date: Mon, 14 Jan 2002 14:25:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Ok - a couple of slightly more specific examples: Web based registration - I goto a conference room and add the conference room phone to the set of places I can be reached. This is valid for the planned duration of this meeting only. Calls to me had best not interrupt my CEO who has the next reservation on the room. Any application that uses presence of an unexpired registered contact in its processing logic. I'm travelling - my softclient registers a contact with my home service (i'm in the airport using a commercial 802.11 service). I tell my home service that I'm good until slightly after I take off to Austrailia. I get called to the gate and end up turning my laptop off (no clean "unregister"). Applications running 6 hours later (while I'm way out over the Pacific and unreachable) had best not be basing their processing on that contact. This would really toast the way some people want to build presence services for example. Let me try stating my objection another way. What does the expiration of a contact header value mean? I think it means "this URI is only valid for this long" - an expired header value should not be used. Where does knowledge of the validity of the contact live? The most authoritative source of that knowledge is the thing that provides that contact. I say to a server "this URI is only good for 20 minutes". I know its good for only 20 minutes, because I've implemented "explode my phone" and I've set the timer. Its not OK for the server to turn around and tell someone else "here's this URI for Robert and it'll be good next Tuesday." That's a flat-out lie. Its fine for the server to turn around and tell me "well, I'm glad you have a URI that's valid for 20 minutes, but I'm only going to keep it around and tell people its valid for 10". When it hands that URI off to someone else (which may be its own routing logic), its handing off a URI that I, as the authority, have claimed will be valid during that time. RjS > >>The real question is how much does it hurt to have > >>that (soft)state in the network? How critical > >>is it to your service that the registrar purge > >>the state at that time? > >> > > > > Potentially alot. (yes, I know the removal time > > will be fuzzy, but if I ask for an hour, > > having stuff stay around for a week will > > break things). > > > I don't feel all that strongly here, as I see points on > both sides. I think much of the issue depends on whether > or not registration times are really used to drive services > or not. > > Robert, I would ask that more specific > examples be provided to assist in resolving the issue. > Also, I'd welcome thoughts on some of the other points > Brett raised, specifically, the fact that there is a backwards > compatibility issue with sending an error response if the interval > is too short. > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 16:21:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19770 for ; Mon, 14 Jan 2002 16:21:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25839 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 16:21:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24044; Mon, 14 Jan 2002 15:47:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24013 for ; Mon, 14 Jan 2002 15:47:56 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18402 for ; Mon, 14 Jan 2002 15:47:52 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0EKl7O20432; Mon, 14 Jan 2002 15:47:08 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0EKl5n28574; Mon, 14 Jan 2002 15:47:06 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 15:47:06 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102AE3C@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Dean Willis'" , sip@ietf.org Cc: jo@ipdialog.com, brian.rosen@marconi.com, rshah@dynamicsoft.com Subject: RE: [Sip] Minutes, SIP WG, IETF 52 Date: Mon, 14 Jan 2002 15:47:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19D3C.A49D5EE0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19D3C.A49D5EE0 Content-Type: text/plain; charset="iso-8859-15" Well, it's definitely my fault for overdosing on the minute taking, but my own set is almost ready. Do you want them? -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Monday, January 14, 2002 3:37 PM To: minutes@ietf.org; sip@ietf.org Cc: jo@ipdialog.com; brian.rosen@marconi.com; rshah@dynamicsoft.com Subject: [Sip] Minutes, SIP WG, IETF 52 Minutes for SIP based on mine and Alan's notes are posted at: http://www.softarmor.com/sipwg/meets/ietf52/notes/minutes.html I'll be traveling this week. If emergency corrections are required, Rakesh (rshah@dynamicsoft.com) may be equipped to edit. Please copy the chairs with requests. -- 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_01C19D3C.A49D5EE0 Content-Type: text/html; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable RE: [Sip] Minutes, SIP WG, IETF 52

Well, it's definitely my fault for overdosing on the = minute taking, but my own set is almost ready.  Do you want = them?

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.c= om]
Sent: Monday, January 14, 2002 3:37 PM
To: minutes@ietf.org; sip@ietf.org
Cc: jo@ipdialog.com; brian.rosen@marconi.com; = rshah@dynamicsoft.com
Subject: [Sip] Minutes, SIP WG, IETF 52



Minutes for SIP based on mine and Alan's notes are = posted at:

http://www.softarmor.com/sipwg/meets/ietf52/notes/minu= tes.html

I'll be traveling this week. If emergency corrections = are required,
Rakesh (rshah@dynamicsoft.com) may be equipped to = edit. Please copy the
chairs with requests.

--
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_01C19D3C.A49D5EE0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 16:21:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19792 for ; Mon, 14 Jan 2002 16:21:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25866 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 16:21:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23956; Mon, 14 Jan 2002 15:45:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23926 for ; Mon, 14 Jan 2002 15:45:51 -0500 (EST) Received: from web11604.mail.yahoo.com (web11604.mail.yahoo.com [216.136.172.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18335 for ; Mon, 14 Jan 2002 15:45:47 -0500 (EST) Message-ID: <20020114204549.38439.qmail@web11604.mail.yahoo.com> Received: from [208.237.135.12] by web11604.mail.yahoo.com via HTTP; Mon, 14 Jan 2002 12:45:49 PST Date: Mon, 14 Jan 2002 12:45:49 -0800 (PST) From: Sean Olson Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time To: Robert Sparks , Jonathan Rosenberg Cc: "'Sean Olson'" , brett@broadsoft.com, sip@ietf.org In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E983@DYN-TX-EXCH-001.dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --- Robert Sparks wrote: > Ok - a couple of slightly more specific examples: > > Web based registration - I goto a conference room > and add > the conference room phone to the set of places I can > be reached. > This is valid for the planned duration of this > meeting only. > Calls to me had best not interrupt my CEO who has > the next > reservation on the room. In this example, an explicit de-registration is really needed to avoid interrupting the next party. And in this specific example, there should be no reason a de-registration could not be performed. > > Any application that uses presence of an unexpired > registered > contact in its processing logic. I'm travelling - my > softclient > registers a contact with my home service (i'm in the > airport using > a commercial 802.11 service). I tell my home service > that I'm good > until slightly after I take off to Austrailia. I get > called to the > gate and end up turning my laptop off (no clean > "unregister"). > Applications running 6 hours later (while I'm way > out over the > Pacific and unreachable) had best not be basing > their processing > on that contact. This would really toast the way > some people want > to build presence services for example. This makes sense. What you are talking about is having an order of magnitude difference between the requested registration expiration and the actual registration expiration. I don't expect this will happen in practice -- at least not in this end of the spectrum. I believe it is more likely that a server would change "1 minute" into "1 hour" than "1 hour" into "8 hours". But I could be wrong. > > Let me try stating my objection another way. > > What does the expiration of a contact header value > mean? > I think it means "this URI is only valid for this > long" - an expired > header value should not be used. Where does > knowledge of the validity > of the contact live? The most authoritative source > of that knowledge > is the thing that provides that contact. I say to a > server "this URI > is only good for 20 minutes". I know its good for > only 20 minutes, > because I've implemented "explode my phone" and I've > set the timer. > Its not OK for the server to turn around and tell > someone else > "here's this URI for Robert and it'll be good next > Tuesday." That's a > flat-out lie. > Its fine for the server to turn around and tell me > "well, I'm glad you have > a URI that's valid > for 20 minutes, but I'm only going to keep it around > and tell people its > valid for 10". When it hands that URI off to someone > else (which may be its > own routing logic), its handing off a URI that I, as > the authority, have > claimed will be valid during that time. A reasonable argument. The point of extending the URI lifetime was not to do this kind of thing. It is meant as a defensive mechanism for the server to say basically that it's timer resolution is greater than what you are attempting. I think that is a reasonable thing to say. If you want to accomplish this through a 4xx response, that is actually fine with me. I would like an explicit response code and header (akin to Retry-After) that would allow the server to reject the registration and suggest a more suitable resolution. > RjS /sean ===== -- Sean Olson __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 16:30:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20320 for ; Mon, 14 Jan 2002 16:30:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26547 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 16:30:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25424; Mon, 14 Jan 2002 16:10:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25395 for ; Mon, 14 Jan 2002 16:10:27 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19389 for ; Mon, 14 Jan 2002 16:10:23 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0EL82kN005423; Mon, 14 Jan 2002 16:08:02 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 16:09:48 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E987@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Sean Olson'" , Robert Sparks , Jonathan Rosenberg Cc: brett@broadsoft.com, sip@ietf.org Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time Date: Mon, 14 Jan 2002 16:09:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > --- Robert Sparks wrote: > > Ok - a couple of slightly more specific examples: > > > > Web based registration - I goto a conference room > > and add > > the conference room phone to the set of places I can > > be reached. > > This is valid for the planned duration of this > > meeting only. > > Calls to me had best not interrupt my CEO who has > > the next > > reservation on the room. > > In this example, an explicit de-registration is > really needed to avoid interrupting the next party. > And in this specific example, there should be no > reason a de-registration could not be performed. Other than I forgot to do so? With the exception of having to accept a small margin of error I disagree that explicit de-registration is called for. Why would you require me to go in and say "I'm not here anymore" when you allow me to say "I'm here for 20 minutes". If you _don't_ allow me to say "I'm here for 20 minutes" (which is the effect of allowing a server to extend the time), then why are you pretending to carry around expirations? From a user's perspective, everything becomes hard state, with all the fail-cases hard state brings. > > > > > Any application that uses presence of an unexpired > > registered > > contact in its processing logic. I'm travelling - my > > softclient > > registers a contact with my home service (i'm in the > > airport using > > a commercial 802.11 service). I tell my home service > > that I'm good > > until slightly after I take off to Austrailia. I get > > called to the > > gate and end up turning my laptop off (no clean > > "unregister"). > > Applications running 6 hours later (while I'm way > > out over the > > Pacific and unreachable) had best not be basing > > their processing > > on that contact. This would really toast the way > > some people want > > to build presence services for example. > > This makes sense. What you are talking about is > having an order of magnitude difference between > the requested registration expiration and the > actual registration expiration. I don't expect this > will happen in practice -- at least not in this > end of the spectrum. I believe it is more likely > that a server would change "1 minute" into "1 hour" > than "1 hour" into "8 hours". But I could be wrong. Eventually, someone will find something where changing 1 minute to 1 hour would be just as damaging. > > > > > Let me try stating my objection another way. > > > > What does the expiration of a contact header value > > mean? > > I think it means "this URI is only valid for this > > long" - an expired > > header value should not be used. Where does > > knowledge of the validity > > of the contact live? The most authoritative source > > of that knowledge > > is the thing that provides that contact. I say to a > > server "this URI > > is only good for 20 minutes". I know its good for > > only 20 minutes, > > because I've implemented "explode my phone" and I've > > set the timer. > > Its not OK for the server to turn around and tell > > someone else > > "here's this URI for Robert and it'll be good next > > Tuesday." That's a > > flat-out lie. > > Its fine for the server to turn around and tell me > > "well, I'm glad you have > > a URI that's valid > > for 20 minutes, but I'm only going to keep it around > > and tell people its > > valid for 10". When it hands that URI off to someone > > else (which may be its > > own routing logic), its handing off a URI that I, as > > the authority, have > > claimed will be valid during that time. > > A reasonable argument. The point of extending the > URI lifetime was not to do this kind of thing. It > is meant as a defensive mechanism for the server > to say basically that it's timer resolution is greater > than what you are attempting. I think that is a > reasonable thing to say. If you want to accomplish > this through a 4xx response, that is actually fine > with me. I would like an explicit response code > and header (akin to Retry-After) that would allow > the server to reject the registration and suggest > a more suitable resolution. This is a better direction to go. > > > RjS > /sean > > > ===== > -- > Sean Olson > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 17:14:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19768 for ; Mon, 14 Jan 2002 16:21:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25833 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 16:21:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23633; Mon, 14 Jan 2002 15:36:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23600 for ; Mon, 14 Jan 2002 15:36:53 -0500 (EST) Received: from valen.greycouncil.com (bdsl.66.12.12.131.gte.net [66.12.12.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17959; Mon, 14 Jan 2002 15:36:48 -0500 (EST) Received: from there (valen.greycouncil.com [127.0.0.1]) by valen.greycouncil.com (8.11.6/8.11.6) with SMTP id g0EKaoB20237; Mon, 14 Jan 2002 14:36:50 -0600 Message-Id: <200201142036.g0EKaoB20237@valen.greycouncil.com> Content-Type: text/plain; charset="iso-8859-15" From: Dean Willis To: minutes@ietf.org, sip@ietf.org Date: Mon, 14 Jan 2002 14:36:49 -0600 X-Mailer: KMail [version 1.3.2] Cc: jo@ipdialog.com, brian.rosen@marconi.com, rshah@dynamicsoft.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] Minutes, SIP WG, IETF 52 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Minutes for SIP based on mine and Alan's notes are posted at: http://www.softarmor.com/sipwg/meets/ietf52/notes/minutes.html I'll be traveling this week. If emergency corrections are required, Rakesh (rshah@dynamicsoft.com) may be equipped to edit. Please copy the chairs with requests. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 18:04:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24002 for ; Mon, 14 Jan 2002 18:04:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29942 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 18:04:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29129; Mon, 14 Jan 2002 17:42:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29065 for ; Mon, 14 Jan 2002 17:42:47 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22956; Mon, 14 Jan 2002 17:42:43 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA26912; Mon, 14 Jan 2002 14:41:56 -0800 (PST) Message-ID: <3C435ED9.EBE9D82B@cisco.com> Date: Mon, 14 Jan 2002 17:42:34 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> <3C3C5199.4444C8F2@cisco.com> <3C3C82D9.32BA8081@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Flemming Andreasen wrote: > > > > It doesn't solve this particular problem by itself, however it provides a > > mechanism that can be used to help solve it while remaining backwards > > compatible. In its present form, you can send an INVITE/offer listing only one > > codec in the "m=" line, and then include all codecs supported in the > > capabilites. The answerer can accept this, and then do another re-INVITE > > picking one or more codecs from the capabilites if you wants to use a different > > one. > > How about a variant of this - an Invite where the offer includes *no* m= > lines, but uses simcap to describe what is available. That wouldn't be backwards compatible or RFC 2327 conformant for that matter. > The recipient > would be expected to accept the invite with no media, perhaps also > returning capabilities. Then one side or the other need to send a > reinvite to establish media. > > This provides the extra round trip to do negotiation. But it requires > significant support from all parties. > Right. Apart from the above, I'm also not a big fan of requiring the extra round-trip. Default behavior should work with just a single round-trip, but further refinement (or changes) may require an extra round. > > An alternative that I was going to mention is to precede the INVITE with > an OPTIONS request to discover what the other side is capable of. But it > suffers from a serious problem - it doesn't establish a dialog, so there > is no guarantee that the subsequent INVITE will go to the same place. Right - good point (it's also SIP specific as opposed to more general offer/answer). -- Flemming > > > 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 daemon@optimus.ietf.org Mon Jan 14 18:08:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24137 for ; Mon, 14 Jan 2002 18:08:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29979 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 18:08:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29293; Mon, 14 Jan 2002 17:47:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29259 for ; Mon, 14 Jan 2002 17:47:09 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23245 for ; Mon, 14 Jan 2002 17:47:06 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.113]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0EMl6Ge017262; Mon, 14 Jan 2002 17:47:07 -0500 (EST) Message-ID: <3C435FC8.3080206@dynamicsoft.com> Date: Mon, 14 Jan 2002 17:46:32 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Osborne CC: sip@ietf.org Subject: Re: [SIP] Use of Branch parameter within Via headers References: <2E33960095B58E40A4D3345AB9F65EC10312AB4F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert Osborne wrote: > Hi, > > Within RFC 2543 section 6.40.5, is the following paragraph: > > The "branch" parameter is included by every forking proxy. The token > MUST be unique for each distinct request generated when a proxy > forks. CANCEL requests MUST have the same branch value as the > corresponding forked request. When a response arrives at the proxy it > can use the branch value to figure out which branch the response > corresponds to. A proxy which generates a single request (non- > forking) MAY also insert the "branch" parameter. The identifier has > to be unique only within a set of isomorphic requests. > >>From this text, all forking proxies should include the "branch" > parameter. > However I was wondering, even though it is a "MAY" for non forking > proxies > to insert this parameter, is there any that do? Yes. Also, note that in bis, we will be mandating the use of branch parameters by every client (proxies, UA) as a transaction identifier. Mechanisms are in place for backwards compatibility, since UA do not insert them, but there is substantial benefit for having them. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 18:42:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25772 for ; Mon, 14 Jan 2002 18:42:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA01056 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 18:42:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00455; Mon, 14 Jan 2002 18:21:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00344 for ; Mon, 14 Jan 2002 18:21:14 -0500 (EST) Received: from boy ([211.202.71.98]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24961 for ; Mon, 14 Jan 2002 18:21:10 -0500 (EST) Message-Id: <200201142321.SAA24961@ietf.org> From: =?ks_c_5601-1987?B?vsbAzLX7tfu1+w==?= To: sip@ietf.org Date: Tue, 15 Jan 2002 08:19:41 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C0F19A.93A41C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sip] =?ks_c_5601-1987?B?W8irurhdILPXxrzB8MDMILi4tecgsMu79r+jwfggvsbAzLX7tfu1+8DUtM+02S4=?= Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C0F19A.93A41C00 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 sMu79r+jwfggvsbAzLX7tfu1+yAgICAgICAgICAgICAgICAgICAgICAgIMDOxc2z3b+htMIg uLnAuiDBpLq4v80gsdcgwaS6uLimIMOjvsbB1rTCILDLu/a/o8H4wMwgwNa9wLTPtNkuDQog IMfPwfa4uCCwy7v2v6PB+LXpwMwgs8q5q7OqILi5wLogwaS6uLimIMGmsPjH2CDB1rTCILDh sPogv8DI97fBIMGkuri4piDDo7TCtaUguLnAuiCz67fCsPogvcOwo8C7DQogICDH47rxx8+0 wiCw4bD6uKYgw8q3ocfPsO0gwNa9wLTPtNkuDQoNCiAgICAgIMDMwaa0wiC+8sC7ILz2IL74 tMIguLnAuiC+58DHILDLu/aw4bD6uri02bTCIL3Ft9q8uiDA1rTCIMGkuri4piC/5LG4x8+0 wiC9w7TrsKEgtce++r3AtM+02S4NCiAgIMDOxc2z3b+hILvqwOfH2CDA1rTCILvnwMzGriDB 37+htMIgv+y4rrChILLAIMfKv+TH0SDBpLq4tenAuyC047DtIMDWtMIgu+fAzMausKEguLnA zCDA1rTCtaUsDQogICDAzCC758DMxq4gtenAuyCxuLrQx8+46SDG98W7LLq4xbssx+O66iC7 58DMxq6287DtIMfVtM+02S4NCg0KICAgICAgvsbAzLX7tfu1+7TCIMDMt7Egu+fAzMauuKYg w6O+xsHWtMIgxKvF17DtuK4gudcgxbC/9rXlILDLu/a/o8H4wNS0z7TZLg0KICAgsKIgxKvF 17DtuK4gurC3ziC9xbfavLogwNa0wiC+9ryxtcggu+fAzMauuLggs9fGvMHwwMcgvue9ycC4 t8617rfPsPy4rsfPtMIgsMu79r+jwfjAzLjnDQogILHNx8+ysryttbUgxKvF17DtuK4gtOO0 58DasKEgtce9xyC89iDA1r3AtM+02S4NCg0KICDEq8XXsO24riC047TnwMwgtce9w7jpIKLf vsbAzL+jwKXAxyDB1r3EIDHB1rimILmru/PAuLfOILXluK645yBwb3AzIGUtbWFpbCCw6MGk wLsgteW4s7TPtNkuDQogICAoIr+5IiBhYmNAaXd3dy5uZXQiKQ0KICAgtsfH0Syx1yDEq8XX sO24rrimILD8uK7H0iC89iDA1rTCILHHx9Gw+iDH2LTnIMSrxdew7biuv6EgtOO058DaIL7G wMy18LimILXut8/H1bTPtNkuDQogICAote63z73Fw7vAuyDHz73FyMQgtOO057D8uK7A2rfO IGxvZ2luIMfPvcO46SDEq8XXsO24rrimIMH3waIgsPy4rsfPvccgvPYgwNa9wLTPtNkuKQ0K ICAgyLi/+LChwNTAuyDHz73DsO0gyLi/+MDMILXHvcO46SCi3yC+xsDMv6PApcDHIMHWvcQg McHWuKYguau788C4t84gteW4s7TPtNkuDQogICDAzsXNs93AuiCz18a8wfDAzCDB1sDOwMyw 7SC+xsDMtfu1+7X7tMIgs9fGvMHwwMcgsM3AzLHiILanua7A1LTPtNkhIA0KDQogICAgaHR0 cDovL2l3d3cubmV0ICi+xsDMtfu1+7X7KbfOILnmua7H2CDB1ry8v+QgICAgIL7GwMy1+7X7 tfvAxyDAzLPkwLogv+y4riCz18a8wfDAzCCwrrDtwNa0wiDAr8DNx9EgwaS6uLimILytt84g sPjAr8fPsO0gu/W3zr/uILPXxrzB8LmuyK24pg0KICAgw6LD4sfPtMKwzcDUtM+02S4gsc3H z7KyvK21tSC+xsDMtfu1+7X7wMcgx9EgsKHBt8DMILXHvu7B1r3DseYgus7FubXluLO0z7TZ Lg0KDQogILTDILDHsK3Hz73DsO0gx+C6ucfPvLy/5H5+frCou+fH1bTPtNkuDQoNCiAgICAg ICAgICAgICAgICAgIDHAzyDG8rHVILnmua4gICA3NzQsNTAwIGhpdCgyMDAyLjAxLjA3KSAg ICAgICAgICAgILPXxrzB8CC047TnIMSrxdew7biuICAgNzQ1ILCzICAgICAgIA0KICDB98Gi ILnmua7Hz7zFvK0gxvKwocfYIMHWvcq9w7/AISA9PT09PT0+aHR0cDovL2l3d3cubmV0wK/A zcfRILvnwMzGrrbzsO0gxvKwobXHvcO46SANCiAgwdbAp7rQtem/obDUIL7Lt8HB1r3Dsea5 2bb4tM+02S4gKCC+xsDMtfu1+7X7ID0gaXd3dyApDQoNCiAgICAgICAgICANCiAgsc3Hz7Ky ILrSxu3AuyCzosPEILXlt8i02bjpIL/rvK24piC52bb4tM+02S4NCiAgsc3Hz8DHILjewM/A uiDAzsXNs92/obytIMClvK3HzsHfIMPrtebHz7+0wLi45yCxzcfPwMcgvu62sMfRIMGkuri1 tSCwrrDtwNbB9iC+yr3AtM+02S4NCg0KICC02cC9us7FzbTCIMDOxc2z3SzBpLq4xeu9xSy5 2cDMt6+9urnpvcUgte4gwK/AzcfRIMGkuri4uMC7ILq4s7u15biztM+02S4gDQogIL7GwMy1 +7X7tfvAxyCwocG3wMwgtce9w7jpIMD8w7ywocG3ILjewM/AuyDF68fPv6kgwK/AzcfRIMGk uri4piC53r7Guri9xyC89iDA1r3AtM+02S4NCiAgsPjB9rvnx9fAuyDC/LDtx8+9w7jpIL7G wMy1+7X7tfsgs7u6zrvnwaTAuyC+xr3HILz2IMDWvcC0z7TZLiC52bfOsKG8rSC6uLHiDQog ILPXxrzB8MDHILDtsN/AuyC89rfFx8+0wiCw+LCzsNS9w8bHwLsgv+6/tcHfwNS0z7TZLrnZ t86wobytILq4seINCiAgILHXt6G1tSC89r3FwLsgv/jEoSC+ysC4vccgsOa/7CC89r3FsMW6 zrimIMWsuK/Hz73KvcO/wCG89r3FsMW6zg0KDQogICAgICAgICAg ------=_NextPart_000_0087_01C0F19A.93A41C00 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQo8aHRtbD4NCjxoZWFkPg0KPHRpdGxlPrDLu/a/o8H4IL7GwMy1+7X7tfs8L3RpdGxlPg0K PHgtbWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsg Y2hhcnNldD1ldWMta3IiPg0KPC9oZWFkPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwh LS0NCkE6bGluaywgQTphY3RpdmUsIEE6dmlzaXRlZCB7DQpmb250LXNpemU6IDlwdDsNCmNv bG9yOiByZWQ7DQp0ZXh0LWRlY29yYXRpb246IG5vbmU7DQp9DQpBOmhvdmVyIHsgDQpmb250 LXNpemU6IDlwdDsNCmNvbG9yOjAwMDAwMDsNCnRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l Ow0KfQ0KVEQgew0KZm9udC1mYW1pbHk6ILG8uLI7DQpmb250LXNpemU6IDlwdDsNCmNvbG9y OiAwMDAwMDA7DQp9DQotLT4NCjwvc3R5bGU+DQo8dGFibGUgd2lkdGg9MTAwJSAgYmdjb2xv cj0iI0I0QjRCNCIgdGV4dD0iIzAwMDAwMCI+PHRkIHZhbGlnbj10b3A+DQo8dGFibGUgd2lk dGg9IjYxOSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIGFs aWduPSJjZW50ZXIiIA0KYmFja2dyb3VuZD0iaHR0cDovL2l3d3cuY28ua3IvaXd3d19pbmZv L2JhY2suZ2lmIj4NCiAgPHRyPiANCiAgICA8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0 b3AiIHdpZHRoPSIxMSI+PGltZyBzcmM9Imh0dHA6Ly9pd3d3LmNvLmtyL2l3d3dfaW5mby9s ZWZ0LmdpZiIgd2lkdGg9IjExIiANCmhlaWdodD0iMjA5Ij48L3RkPg0KICAgIDx0ZCBhbGln bj0iY2VudGVyIiB2YWxpZ249InRvcCIgd2lkdGg9IjU4NiI+IA0KICAgICAgPHRhYmxlIHdp ZHRoPSIxMDAlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIg DQpiYWNrZ3JvdW5kPSJodHRwOi8vaXd3dy5jby5rci9pd3d3X2luZm8vY19iYWNrLmdpZiI+ DQogICAgICAgIDx0cj4gDQogICAgICAgICAgPHRkPjxhIGhyZWY9Imh0dHA6Ly9pd3d3Lm5l dCIgdGFyZ2V0PSJfYmxhbmsiPjxpbWcgDQpzcmM9Imh0dHA6Ly9pd3d3LmNvLmtyL2l3d3df aW5mby9sb2dvLmdpZiIgd2lkdGg9IjU4NiIgaGVpZ2h0PSI0MCIgYm9yZGVyPSIwIj48L2E+ PC90ZD4NCiAgICAgICAgPC90cj4NCiAgICAgICAgPHRyPiANCiAgICAgICAgICA8dGQ+PGlt ZyBzcmM9Imh0dHA6Ly9pd3d3LmNvLmtyL2l3d3dfaW5mby9sb2dvX3R4dC5naWYiIHdpZHRo PSI1ODYiIGhlaWdodD0iMTAwIj48L3RkPg0KICAgICAgICA8L3RyPg0KICAgICAgICA8dHI+ IA0KICAgICAgICAgIDx0ZD4gDQogICAgICAgICAgICA8dGFibGUgd2lkdGg9IjEwMCUiIGNl bGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYm9yZGVyPSIxIiBib3JkZXJjb2xvcj0i IzYxOTRERCIgYm9yZGVyY29sb3JkYXJrPSIjRkZGRkZGIj4NCiAgICAgICAgICAgICAgPHRy PiANCiAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiIGhl aWdodD0iNjkiPiANCiAgICAgICAgICAgICAgICAgIDx0YWJsZSBiZ2NvbG9yPSIjOThCMUQx IiB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9 IjAiPg0KICAgICAgICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgICAgICAg IDx0ZCB3aWR0aD0iOTYlIj4mbmJzcDs8L3RkPg0KICAgICAgICAgICAgICAgICAgICA8L3Ry Pg0KICAgICAgICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgICAgICAgIDx0 ZCB3aWR0aD0iOTYlIiBoZWlnaHQ9IjE4Ij4mbmJzcDsmbmJzcDvAzsXNs92/obTCILi5wLog waS6uL/NILHXIMGkuri4piDDo77Gwda0wiCwy7v2v6PB+MDMIMDWvcC0z7TZLjxicj4NCiZu YnNwOyZuYnNwO8fPwfa4uCCwy7v2v6PB+LXpwMwgs8q5q7OqILi5wLogwaS6uLimIMGmsPjH 2CDB1rTCILDhsPogv8DI97fBIMGkuri4piDDo7TCtaUguLnAuiCz67fCsPogvcOwo8C7PGJy PiAgDQombmJzcDsmbmJzcDvH47rxx8+0wiCw4bD6uKYgw8q3ocfPsO0gwNa9wLTPtNkuPGJy Pjxicj4gDQo8L3RkPg0KICAgICAgICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAg ICAgICAgICA8dHI+IA0KICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iOTYlIiBo ZWlnaHQ9IjE4Ij4NCiZuYnNwOyZuYnNwO8DMwaa0wiC+8sC7ILz2IL74tMIguLnAuiC+58DH ILDLu/aw4bD6uri02bTCIL3Ft9q8uiDA1rTCIMGkuri4piC/5LG4x8+0wiC9w7TrsKEgtce+ +r3AtM+02S48YnI+ICANCiZuYnNwOyZuYnNwO8DOxc2z3b+hILvqwOfH2CDA1rTCILvnwMzG riDB37+htMIgv+y4rrChILLAIMfKv+TH0SDBpLq4tenAuyC047DtIMDWtMIgu+fAzMausKEg uLnAzCDA1rTCtaUsPGJyPiAgIA0KJm5ic3A7Jm5ic3A7wMwgu+fAzMauILXpwLsgsbi60MfP uOkgPGEgaHJlZj0iaHR0cDovL2l3d3cubmV0L3BvcnRhbC5odG1sIiB0YXJnZXQ9Il9ibGFu ayI+xvfFuyy6uMW7LMfjuuo8L2E+ILvnwMzGrrbzsO0gx9W0z7TZLjxicj48YnI+ICANCjwv dGQ+DQogICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgIDx0 cj4gDQogICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI5NiUiPg0KJm5ic3A7Jm5i c3A7vsbAzLX7tfu1+7TCIMDMt7Egu+fAzMauuKYgw6O+xsHWtMIgxKvF17DtuK4gudcgxbC/ 9rXlILDLu/a/o8H4wNS0z7TZLjxicj4gIA0KJm5ic3A7Jm5ic3A7sKIgxKvF17DtuK4gurC3 ziC9xbfavLogwNa0wiC+9ryxtcggu+fAzMauuLggs9fGvMHwwMcgvue9ycC4t84NCjxhIGhy ZWY9Imh0dHA6Ly9pd3d3Lm5ldC9kYXRhL2NhdF9saXN0Lmh0bWwiIHRhcmdldD0iX2JsYW5r Ij617rfPsPy4rjwvYT7Hz7TCILDLu/a/o8H4wMy45zxicj4NCiZuYnNwOyZuYnNwO7HNx8+y sryttbUgxKvF17DtuK4gtOO058DasKEgtce9xyC89iDA1r3AtM+02S48YnI+PGJyPg0KDQoN CiZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9pd3d3Lm5ldC9teV9zaWdudXAuaHRtbCIg dGFyZ2V0PSJfYmxhbmsiPsSrxdew7biuILTjtOc8L2E+wMwgtce9w7jpIKLfvsbAzL+jwKXA xyDB1r3EIDHB1rimILmru/PAuLfOILXluK645yBwb3AzIGUtbWFpbCCw6MGkwLsgteW4s7TP tNkuPGJyPiAgDQombmJzcDsmbmJzcDsoIr+5IiBhYmNAaXd3dy5uZXQiKTxicj4gICANCiZu YnNwOyZuYnNwO7bHx9EssdcgxKvF17DtuK64piCw/Liux9IgvPYgwNa0wiCxx8fRsPogx9i0 5yDEq8XXsO24rr+hILTjtOfA2iC+xsDMtfC4piC17rfPx9W0z7TZLjxicj4gICANCiZuYnNw OyZuYnNwOyi17rfPvcXDu8C7IMfPvcXIxCC047TnsPy4rsDat84gbG9naW4gx8+9w7jpIMSr xdew7biuuKYgwffBoiCw/Liux8+9xyC89iDA1r3AtM+02S4pPGJyPiAgIA0KDQombmJzcDsm bmJzcDs8YSBocmVmPSJodHRwOi8vaXd3dy5uZXQvc2lnbnVwLmh0bWwiIHRhcmdldD0iX2Js YW5rIj7IuL/4sKHA1DwvYT7AuyDHz73DsO0gyLi/+MDMILXHvcO46SCi3yC+xsDMv6PApcDH IMHWvcQgMcHWuKYguau788C4t84gteW4s7TPtNkuPGJyPiAgDQombmJzcDsmbmJzcDvAzsXN s93AuiCz18a8wfDAzCDB1sDOwMyw7SC+xsDMtfu1+7X7tMIgs9fGvMHwwMcgsM3AzLHiILan ua7A1LTPtNkhIDxicj4gIDxicj4gIA0KDQoNCg0KPC90ZD48L3RyPg0KIDx0cj4gDQogICAg ICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI5NiUiIGhlaWdodD0iMTkiPjxiPjxmb250 IGNvbG9yPSIjRkY5OTAwIj4NCiZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9pd3d3Lm5l dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9pd3d3Lm5ldDwvYT48L2ZvbnQ+PC9iPiAovsbA zLX7tfu1+ym3ziC55rmux9ggwda8vL/kPC90ZD4NCiAgICAgICAgICAgICAgICAgICAgPC90 cj4NCiA8dHI+IA0KICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iOTYlIiBoZWln aHQ9IjE5Ij4NCiZuYnNwOyZuYnNwO77GwMy1+7X7tfvAxyDAzLPkwLogv+y4riCz18a8wfDA zCCwrrDtwNa0wiDAr8DNx9EgwaS6uLimILytt84gsPjAr8fPsO0gu/W3zr/uILPXxrzB8Lmu yK24pjxicj4gDQombmJzcDsmbmJzcDvDosPix8+0wrDNwNS0z7TZLiCxzcfPsrK8rbW1IL7G wMy1+7X7tfvAxyDH0SCwocG3wMwgtce+7sHWvcOx5iC6zsW5teW4s7TPtNkuPGJyPjxicj4N Cg0KJm5ic3A7Jm5ic3A7tMMgsMewrcfPvcOw7SDH4Lq5x8+8vL/kfn5+sKi758fVtM+02S48 YnI+PGJyPg0KDQoNCjwvdGQ+DQogICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAg ICAgICAgICAgICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAg ICAgICAgDQogICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgIDx0cj4gDQogICAg ICAgICAgICAgICAgPHRkIHdpZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIiB2YWxpZ249InRv cCI+IA0KICAgICAgICAgICAgICAgICAgICA8dGFibGUgd2lkdGg9IjEwMCUiIGJvcmRlcj0i MCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCiAgICAgICAgICAgICAgICAg ICAgPHRyIGJnY29sb3I9IiMwMDAwMDAiPiANCiAgICAgICAgICAgICAgICAgICAgICA8dGQg d2lkdGg9IjclIiBoZWlnaHQ9IjEiPjwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAgPHRk IHdpZHRoPSI0MyUiIGhlaWdodD0iMSI+PC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICA8 dGQgd2lkdGg9IjQlIiBoZWlnaHQ9IjEiPjwvdGQ+DQogICAgICAgICAgICAgICAgICAgICAg PHRkIHdpZHRoPSI0NiUiIGhlaWdodD0iMSI+PC90ZD4NCiAgICAgICAgICAgICAgICAgICAg PC90cj4NCiAgICAgICAgICAgICAgICAgICAgPHRyPiANCiAgICAgICAgICAgICAgICAgICAg ICA8dGQgd2lkdGg9IjclIiBoZWlnaHQ9IjIwIiBiZ2NvbG9yPSIjOTlDQ0NDIj4mbmJzcDs8 L3RkPg0KICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNDMlIiBoZWlnaHQ9IjIw IiBiZ2NvbG9yPSIjOTlDQ0NDIj48Yj4xwM8gxvKx1SC55rmuPC9iPjwvdGQ+DQogICAgICAg ICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI0JSIgaGVpZ2h0PSIyMCIgYmdjb2xvcj0iI2Vk ZWRlZCI+Jm5ic3A7PC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjQ2 JSIgaGVpZ2h0PSIyMCIgYmdjb2xvcj0iI2VkZWRlZCI+PGI+PGZvbnQgY29sb3I9IiM2NjY2 NjYiPjc3NCw1MDAgaGl0KDIwMDIuMDEuMDcpDQo8L2ZvbnQ+PC9iPjwvdGQ+DQogICAgICAg ICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgICAgIDx0cj4gDQogICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI3JSIgaGVp Z2h0PSIxIiBiZ2NvbG9yPSIjMDAwMDAwIj48L3RkPg0KICAgICAgICAgICAgICAgICAgICAg IDx0ZCB3aWR0aD0iNDMlIiBoZWlnaHQ9IjEiIGJnY29sb3I9IiMwMDAwMDAiPjwvdGQ+DQog ICAgICAgICAgICAgICAgICAgICAgPHRkIHdpZHRoPSI0JSIgaGVpZ2h0PSIxIiBiZ2NvbG9y PSIjMDAwMDAwIj48L3RkPg0KICAgICAgICAgICAgICAgICAgICAgIDx0ZCB3aWR0aD0iNDYl IiBoZWlnaHQ9IjEiIGJnY29sb3I9IiMwMDAwMDAiPjwvdGQ+DQogICAgICAgICAgICAgICAg ICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgIDx0cj4gDQogICAgICAgICAgICAgICAg ICAgICAgPHRkIHdpZHRoPSI3JSIgaGVpZ2h0PSIyMCIgYmdjb2xvcj0iIzk5Q0NDQyI+Jm5i c3A7PC90ZD4NCiAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjQzJSIgaGVpZ2h0 PSIyMCIgYmdjb2xvcj0iIzk5Q0NDQyI+PGI+s9fGvMHwILTjtOcgxKvF17DtuK48L2I+PC90 ZD4NCiAgICAgICAgICAgICAgICAgICAgICA8dGQgd2lkdGg9IjQlIiBoZWlnaHQ9IjIwIiBi Z2NvbG9yPSIjZWRlZGVkIj4mbmJzcDs8L3RkPg0KICAgICAgICAgICAgICAgICAgICAgIDx0 ZCB3aWR0aD0iNDYlIiBoZWlnaHQ9IjIwIiBiZ2NvbG9yPSIjZWRlZGVkIj48Yj48Zm9udCBj b2xvcj0iIzY2NjY2NiI+DQo8YSBocmVmPSJodHRwOi8vaXd3dy5uZXQvZGF0YS9jYXRfbGlz dC5odG1sIiB0YXJnZXQ9Il9uZXciPjc0NSCwszwvYT48L2ZvbnQ+PC9iPjwvdGQ+DQogICAg ICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAg ICAgICAgICAgPC90YWJsZT4NCiAgICAgICAgICAgICAgICAgIDx0YWJsZSB3aWR0aD0iMTAw JSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KICAgICAg ICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICA8dHI+IA0KICAgICAgICAgICAg ICAgICAgICAgIDx0ZCBiZ2NvbG9yPSIjQ0VDRUNFIiBoZWlnaHQ9IjE4Ij48Zm9udCBjb2xv cj0iIzAwMDA4MCI+PGJyPg0KJm5ic3A7Jm5ic3A7wffBoiC55rmux8+8xbytIMbysKHH2CDB 1r3KvcO/wCEgPT09PT09Jmd0OzxhIGhyZWY9Imh0dHA6Ly9pd3d3Lm5ldCIgdGFyZ2V0PSJf bmV3Ij48Zm9udCBjb2xvcj0iIzA2MDZGRiI+aHR0cDovL2l3d3cubmV0PC9mb250PjwvYT4N CsCvwM3H0SC758DMxq6287DtIMbysKG1x73DuOkgPGJyPg0KJm5ic3A7Jm5ic3A7wdbAp7rQ tem/obDUIL7Lt8HB1r3Dsea52bb4tM+02S4gKCC+xsDMtfu1+7X7ID0gaXd3dyApPGJyPg0K PGJyPjwvdGQ+DQogICAgICAgICAgICAgICAgICAgIDwvdHI+DQogICAgICAgICAgICAgICAg ICA8L3RhYmxlPg0KICAgICAgICAgICAgICAgIDwvdGQ+DQogICAgICAgICAgICAgICAgIA0K ICAgICAgICAgICAgICA8L3RyPg0KICAgICAgICAgICAgPC90YWJsZT4NCiAgICAgICAgICA8 L3RkPg0KICAgICAgICA8L3RyPg0KDQogPHRyPiANCiAgICAgICAgICA8dGQgaGVpZ2h0PSIy MCIgYmdjb2xvcj0iIzQwNTY4MCIgYWxpZ249ImxlZnQiPjxmb250IGNvbG9yPSIjZmZmZmZm Ij48YnI+DQoNCiZuYnNwOyZuYnNwO7HNx8+ysiC60sbtwLsgs6LDxCC15bfItNm46SC/67yt uKYgudm2+LTPtNkuPGJyPg0KDQombmJzcDsmbmJzcDuxzcfPwMcguN7Az8C6IMDOxc2z3b+h vK0gwKW8rcfOwd8gw+u15sfPv7TAuLjnILHNx8/AxyC+7rawx9EgwaS6uLW1ILCusO3A1sH2 IL7KvcC0z7TZLjxicj48YnI+DQombmJzcDsmbmJzcDu02cC9us7FzbTCIMDOxc2z3SzBpLq4 xeu9xSy52cDMt6+9urnpvcUgte4gwK/AzcfRIMGkuri4uMC7ILq4s7u15biztM+02S4gPGJy Pg0KJm5ic3A7Jm5ic3A7vsbAzLX7tfu1+8DHILChwbfAzCC1x73DuOkgwPzDvLChwbcguN7A z8C7IMXrx8+/qSDAr8DNx9EgwaS6uLimILnevsa6uL3HILz2IMDWvcC0z7TZLjxicj4NCiZu YnNwOyZuYnNwO7D4wfa758fXwLsgwvyw7cfPvcO46SC+xsDMtfu1+7X7ILO7us6758GkwLsg vsa9xyC89iDA1r3AtM+02S48QSBIUkVGPSJodHRwOi8vaXd3dy5uZXQvYmJzLmh0bWwiIHRh cmdldD0iX25ldyI+DQo8Zm9udCBjb2xvcj0iYmx1ZSI+ILnZt86wobytILq4seI8L2ZvbnQ+ PC9hPjxicj4NCiZuYnNwOyZuYnNwO7PXxrzB8MDHILDtsN/AuyC89rfFx8+0wiCw+LCzsNS9 w8bHwLsgv+6/tcHfwNS0z7TZLg0KPGEgaHJlZj0iaHR0cDovL2l3d3cubmV0L3d3d2IvQ3Jh enlXV1dCb2FyZC5jZ2k/ZGI9Ym9hcmQxIiB0YXJnZXQ9Il9uZXciPjxmb250IGNvbG9yPSJi bHVlIj652bfOsKG8rSC6uLHiPC9mb250PjwvYT48YnI+DQogIA0KJm5ic3A7Jm5ic3A7sde3 obW1ILz2vcXAuyC/+MShIL7KwLi9xyCw5r/sILz2vcWwxbrOuKYgxay4r8fPvcq9w7/AITwv Zm9udD4NCjxBIEhSRUY9bWFpbHRvOml3ZWJtYXN0ZXJAaXd3dy5uZXQ/c3ViamVjdD289r3F sMW6ziZib2R5PbjewM+89r3FsMW6zj4NCjxmb250IGNvbG9yPSJibHVlIj48Yj689r3FsMW6 zjwvYj48L2ZvbnQ+PC9BPjxicj48YnI+IA0KICAgICAgICAgIDwvdGQ+DQogICAgICAgIDwv dHI+DQogICAgICA8L3RhYmxlPg0KICAgIDwvdGQ+DQogICAgPHRkIGFsaWduPSJjZW50ZXIi IHZhbGlnbj0idG9wIiB3aWR0aD0iMjIiPjxpbWcgc3JjPSJodHRwOi8vaXd3dy5jby5rci9p d3d3X2luZm8vcmlnaHQuZ2lmIiB3aWR0aD0iMjIiIA0KaGVpZ2h0PSIyMDkiPjwvdGQ+DQog IDwvdHI+DQo8L3RhYmxlPg0KPHRhYmxlIHdpZHRoPSI2MTkiIGJvcmRlcj0iMCIgY2VsbHNw YWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiBhbGlnbj0iY2VudGVyIj4NCiAgPHRyPg0KICAg IDx0ZD48YSBocmVmPSJodHRwOi8vaXd3dy5uZXQiIHRhcmdldD0iX25ldyI+PGltZyBzcmM9 Imh0dHA6Ly9pd3d3Lm5ldC9pd3d3X2luZm8vYnV0dG9tMS5naWYiIA0Kd2lkdGg9IjYxOSIg aGVpZ2h0PSI0NiIgYm9yZGVyPSIwIj48L2E+PC90ZD4NCiAgPC90cj4NCjwvdGFibGU+DQo8 L3RkPjwvdGFibGU+DQo8L2h0bWw+ ------=_NextPart_000_0087_01C0F19A.93A41C00-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 19:12:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26752 for ; Mon, 14 Jan 2002 19:12:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01981 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 19:12:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01250; Mon, 14 Jan 2002 18:50:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01181 for ; Mon, 14 Jan 2002 18:50:22 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26153; Mon, 14 Jan 2002 18:50:18 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0ENo2418140; Mon, 14 Jan 2002 18:50:02 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAA52438 (AUTH pkyzivat); Mon, 14 Jan 2002 18:52:30 -0500 (EST) Message-ID: <3C436D86.C11A0FED@cisco.com> Date: Mon, 14 Jan 2002 18:45:10 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> <3C3C5199.4444C8F2@cisco.com> <3C3C82D9.32BA8081@cisco.com> <3C435ED9.EBE9D82B@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Flemming - more comments below. Paul Flemming Andreasen wrote: > > Paul Kyzivat wrote: > > > Flemming Andreasen wrote: > > > > > > It doesn't solve this particular problem by itself, however it provides a > > > mechanism that can be used to help solve it while remaining backwards > > > compatible. In its present form, you can send an INVITE/offer listing only one > > > codec in the "m=" line, and then include all codecs supported in the > > > capabilites. The answerer can accept this, and then do another re-INVITE > > > picking one or more codecs from the capabilites if you wants to use a different > > > one. > > > > How about a variant of this - an Invite where the offer includes *no* m= > > lines, but uses simcap to describe what is available. > > That wouldn't be backwards compatible or RFC 2327 conformant for that matter. Why? It is legal to negotiate a media-less session. And an SDP body constitutes an offer even if it doesn't contain any m= lines. This would of course mean that the capability descriptions would all have to be session-level. So, the offer would contain a request for a session with no media, but with capability descriptions for supported media. The response would agree to the session with no media and return capability descriptions. Then one side or the other would initiate a re-invite, offering media compatible with the capabilities supported by both sides. > > > The recipient > > would be expected to accept the invite with no media, perhaps also > > returning capabilities. Then one side or the other need to send a > > reinvite to establish media. > > > > This provides the extra round trip to do negotiation. But it requires > > significant support from all parties. > > > > Right. Apart from the above, I'm also not a big fan of requiring the extra > round-trip. Default behavior should work with just a single round-trip, but further > refinement (or changes) may require an extra round. Well, you only do this if you don't know what to offer initially. You can also implement half of this techique: if you receive an offer with media that you can't support, you could accept the invite but refuse the media, and include a simcap description of what you would be willing to accept. Then hope for a reinvite. If the offerer doesn't know how to deal with this, ought to send bye to media-less session. > > > > > An alternative that I was going to mention is to precede the INVITE with > > an OPTIONS request to discover what the other side is capable of. But it > > suffers from a serious problem - it doesn't establish a dialog, so there > > is no guarantee that the subsequent INVITE will go to the same place. > > Right - good point (it's also SIP specific as opposed to more general offer/answer). > > -- Flemming > > > > > > > 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 daemon@optimus.ietf.org Mon Jan 14 20:33:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28655 for ; Mon, 14 Jan 2002 20:33:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA04762 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 20:33:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03063; Mon, 14 Jan 2002 19:53:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03032 for ; Mon, 14 Jan 2002 19:53:08 -0500 (EST) Received: from fox.iptel.org (fox.iptel.org [195.37.77.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27741 for ; Mon, 14 Jan 2002 19:53:05 -0500 (EST) Received: from jku.fokus.gmd.de (1Cust27.max3.par2.fra.da.uu.net [195.129.11.219]) by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g0F0qPH14197; Tue, 15 Jan 2002 01:52:25 +0100 Message-Id: <5.1.0.14.0.20020114222343.0377de68@mailhost.fokus.gmd.de> X-Sender: jku@mailhost.fokus.gmd.de X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 14 Jan 2002 22:28:15 +0100 To: "Robert Osborne" , From: Jiri Kuthan Subject: Re: [SIP] Use of Branch parameter within Via headers In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC10312AB4F@win-msg-01.wingro up.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Actually, the plan is to have branch included by every UAc -- see the open issue #144. -Jiri At 06:06 PM 1/14/2002, Robert Osborne wrote: >Hi, > > > >Within RFC 2543 section 6.40.5, is the following paragraph: > > > > The "branch" parameter is included by every forking proxy. The token > > MUST be unique for each distinct request generated when a proxy > > forks. CANCEL requests MUST have the same branch value as the > > corresponding forked request. When a response arrives at the proxy it > > can use the branch value to figure out which branch the response > > corresponds to. A proxy which generates a single request (non- > > forking) MAY also insert the "branch" parameter. The identifier has > > to be unique only within a set of isomorphic requests. > > > >From this text, all forking proxies should include the branch parameter. > >However I was wondering, even though it is a MAY for non forking proxies > >to insert this parameter, is there any that do? > > > >Rob O > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 14 22:59:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03514 for ; Mon, 14 Jan 2002 22:59:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA09258 for sip-archive@odin.ietf.org; Mon, 14 Jan 2002 22:59:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08450; Mon, 14 Jan 2002 22:33:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA08375 for ; Mon, 14 Jan 2002 22:33:15 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02898; Mon, 14 Jan 2002 22:33:10 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA05394; Mon, 14 Jan 2002 19:32:30 -0800 (PST) Message-ID: <3C43A2EE.1C9F8842@cisco.com> Date: Mon, 14 Jan 2002 22:33:02 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> <3C3C5199.4444C8F2@cisco.com> <3C3C82D9.32BA8081@cisco.com> <3C435ED9.EBE9D82B@cisco.com> <3C436D86.C11A0FED@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Flemming - more comments below. > > Paul > > Flemming Andreasen wrote: > > > > Paul Kyzivat wrote: > > > > > Flemming Andreasen wrote: > > > > > > > > It doesn't solve this particular problem by itself, however it provides a > > > > mechanism that can be used to help solve it while remaining backwards > > > > compatible. In its present form, you can send an INVITE/offer listing only one > > > > codec in the "m=" line, and then include all codecs supported in the > > > > capabilites. The answerer can accept this, and then do another re-INVITE > > > > picking one or more codecs from the capabilites if you wants to use a different > > > > one. > > > > > > How about a variant of this - an Invite where the offer includes *no* m= > > > lines, but uses simcap to describe what is available. > > > > That wouldn't be backwards compatible or RFC 2327 conformant for that matter. > > Why? It is legal to negotiate a media-less session. And an SDP body > constitutes an offer even if it doesn't contain any m= lines. This would > of course mean that the capability descriptions would all have to be > session-level. > You're right - my mistake. > > So, the offer would contain a request for a session with no media, but > with capability descriptions for supported media. The response would > agree to the session with no media and return capability descriptions. Or, if it was an old implementation, it might return an SDP with media streams and formats it's willing to support. > > Then one side or the other would initiate a re-invite, offering media > compatible with the capabilities supported by both sides. > > > > > > The recipient > > > would be expected to accept the invite with no media, perhaps also > > > returning capabilities. Then one side or the other need to send a > > > reinvite to establish media. > > > > > > This provides the extra round trip to do negotiation. But it requires > > > significant support from all parties. > > > > > > > Right. Apart from the above, I'm also not a big fan of requiring the extra > > round-trip. Default behavior should work with just a single round-trip, but further > > refinement (or changes) may require an extra round. > > Well, you only do this if you don't know what to offer initially. > OK, however there are other downsides to this: - How do you handle a 1xx response to the first INVITE ? - What do you do if it turns out that you don't have any media formats in common, and now the called party is being alerted and/or has already answered ? > > You can also implement half of this techique: if you receive an offer > with media that you can't support, you could accept the invite but > refuse the media, and include a simcap description of what you would be > willing to accept. Then hope for a reinvite. If the offerer doesn't know > how to deal with this, ought to send bye to media-less session. You could do this, but it sounds a little fragile to me (e.g. consider clipping, no media formats in common, etc.) -- Flemming _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 15 06:55:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18978 for ; Tue, 15 Jan 2002 06:55:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA01971 for sip-archive@odin.ietf.org; Tue, 15 Jan 2002 06:55:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00922; Tue, 15 Jan 2002 06:27:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00891 for ; Tue, 15 Jan 2002 06:27:42 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17699; Tue, 15 Jan 2002 06:27:40 -0500 (EST) Message-Id: <200201151127.GAA17699@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 15 Jan 2002 06:27:40 -0500 Subject: [Sip] I-D ACTION:draft-sparks-sip-looseroute-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Exploring the Loose Route Proposal Author(s) : R. Sparks Filename : draft-sparks-sip-looseroute-00.txt Pages : 18 Date : 14-Jan-02 This memo documents a proposal to allow SIP elements to use local policy when processing requests containing Route header fields. It identifies two restrictions on that local policy and provides an algorithm for satisfying one of those restrictions. It also presents several example flows utilizing policies enabled by this proposal. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sparks-sip-looseroute-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-sparks-sip-looseroute-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-sparks-sip-looseroute-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020114175019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sparks-sip-looseroute-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sparks-sip-looseroute-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020114175019.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 15 07:55:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20765 for ; Tue, 15 Jan 2002 07:55:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03848 for sip-archive@odin.ietf.org; Tue, 15 Jan 2002 07:55:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03157; Tue, 15 Jan 2002 07:30:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03130 for ; Tue, 15 Jan 2002 07:30:35 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19921 for ; Tue, 15 Jan 2002 07:30:32 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 15 Jan 2002 12:30:59 UT Received: from neil ([193.195.52.196]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 15 Jan 2002 12:31:18 +0000 From: "Neil Deason" To: Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Date: Tue, 15 Jan 2002 12:31:18 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3C3B474B.4050609@dynamicsoft.com> X-OriginalArrivalTime: 15 Jan 2002 12:31:18.0263 (UTC) FILETIME=[87EA1070:01C19DC0] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Christer Holmberg wrote: > > > Hi, > > > > > >>Anyone for deprecating loop detection? A proxy that doesn't > do it would > >>have to insert max-forwards if not already present, that is the > >> > > penalty. > > > >>We also need a minimum value for Max-Forwards, something like 20 is > >>more than sufficient, I think. > >> > > > > Do we need to specify a minimum value in the spec? I think > the value is > > something which is very dependent on the size and > architechture of the > > network, and should be configurable. > > > That is a recipe for disaster. Big disasters. > > Remember, calls go between domains that are frequently not in > any kind > of business relationship. I have no way of knowing what kind > of network > is downstream. So, we choose a value which is sufficiently large to > cover all realistic cases. Having it configurable means it could be > right today, but wrong tomorrow. Shall I have all my > customers support > calls get forwarded to you, Christer, so you can explain why a call > yesterday won't work today because a different network provider > installed a new proxy? If we have no way of knowing what network SIP will run over now, or in the future, what is guaranteed to always be a large enough number? Though this will create inefficient network usage. It is unclear how B2BUAs would interact with Max-Forwards headers as they pass through their UAS|UAC state machine. RFC2543 UAs may (i.e. will) not typically add in Max-Forwards RFC 2543 Proxies certainly wont add it where omitted. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 15 09:51:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25501 for ; Tue, 15 Jan 2002 09:51:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA08872 for sip-archive@odin.ietf.org; Tue, 15 Jan 2002 09:51:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07099; Tue, 15 Jan 2002 09:26:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07075 for ; Tue, 15 Jan 2002 09:26:29 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24426 for ; Tue, 15 Jan 2002 09:26:26 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0FEPuL10044 for ; Tue, 15 Jan 2002 09:25:57 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Jan 2002 14:25:56 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0042468F7@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Tue, 15 Jan 2002 14:25:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Sip] [bis-05] Table 3 and the Supported header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In Table 3 of the bis-05 draft, the Supported header is included. In this table the entry for "Where" is missing. In addition, the entry for "proxy" is blank. The timer draft contains procedures for proxies looking at the contents of the Supported header in a request, to see if the "timer" option-tag is included. I therefore assume that at least for requests, there should be an "r" in the proxy column. If the "r" only applies for requests, then this header needs to be split into two rows, identified in the Where column by "R" and "r" respectively. If the behaviour is the same for both request and response, then the Where column should contain the value "g". Incidently, while the value "g" is used in this table, it is not defined in the key at the start of the table. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 15 09:56:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25726 for ; Tue, 15 Jan 2002 09:56:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA09131 for sip-archive@odin.ietf.org; Tue, 15 Jan 2002 09:56:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07751; Tue, 15 Jan 2002 09:33:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07682 for ; Tue, 15 Jan 2002 09:33:15 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24698; Tue, 15 Jan 2002 09:33:12 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0FEWsI17909; Tue, 15 Jan 2002 09:32:54 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAA54599 (AUTH pkyzivat); Tue, 15 Jan 2002 09:35:21 -0500 (EST) Message-ID: <3C443C71.AD511964@cisco.com> Date: Tue, 15 Jan 2002 09:28:01 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> <3C3C5199.4444C8F2@cisco.com> <3C3C82D9.32BA8081@cisco.com> <3C435ED9.EBE9D82B@cisco.com> <3C436D86.C11A0FED@cisco.com> <3C43A2EE.1C9F8842@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit more comments below. Paul Flemming Andreasen wrote: > > OK, however there are other downsides to this: > - How do you handle a 1xx response to the first INVITE ? Nothing special - just keep waiting. > - What do you do if it turns out that you don't have any media formats in common, and now > the called party is being alerted and/or has already answered ? Just send a BYE I suppose. This isn't any different than if you send an INVITE without an offer, and the offer you receive isn't acceptable. > > > > > You can also implement half of this techique: if you receive an offer > > with media that you can't support, you could accept the invite but > > refuse the media, and include a simcap description of what you would be > > willing to accept. Then hope for a reinvite. If the offerer doesn't know > > how to deal with this, ought to send bye to media-less session. > > You could do this, but it sounds a little fragile to me (e.g. consider clipping, no media > formats in common, etc.) Yeah, it might me. I don't see this as a great solution. But then I wasn't seeing any great solutions being offered, so I thought I would throw it into the pot. The problem is bigger than "supporting just one codec at a time", and the solution should also be. The general problem is that negotiating media sessions is a lot more complex than just picking one or more codecs to use. E.g. we may need to choose from among different transports for the same kind of medium. (This is looking like it may be a problem with IM.) 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 daemon@optimus.ietf.org Tue Jan 15 10:25:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28839 for ; Tue, 15 Jan 2002 10:25:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA10191 for sip-archive@odin.ietf.org; Tue, 15 Jan 2002 10:25:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09738; Tue, 15 Jan 2002 10:05:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09705 for ; Tue, 15 Jan 2002 10:05:18 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26934 for ; Tue, 15 Jan 2002 10:05:15 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0FF5I918837 for ; Tue, 15 Jan 2002 17:05:18 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Jan 2002 17:05:14 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 15 Jan 2002 17:05:01 +0200 content-class: urn:content-classes:message Subject: RE: [Sip] Attention - comment on Loose Routing draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 15 Jan 2002 17:05:01 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [Sip] Attention - comment on Loose Routing draft Thread-Index: AcGdLZnfRko9ovHSRDWTeMfLRWE5fQAhScag From: "Honeisen Bernhard (NET/Helsinki)" To: Cc: "'ext Robert Sparks'" X-OriginalArrivalTime: 15 Jan 2002 15:05:01.0389 (UTC) FILETIME=[015367D0:01C19DD6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA09706 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi RjS! Some question: Consider a situation, where a request is directed to (B) and two service elements (X) and (Y) have to be visited before. (X) performs a service, which replaces the intended destination URL, i.e. (B), whereas (Y) executes some feature, which depends on the output of (X). When the request arrives at (X), the R-URI / Route could look like: - R-URI: - Route: , (The intended destination has been appended earlier to Route as per section 5.2 in your I/D) How can (X) now apply the destination URL relacing feature? My first guess was, that (X) would modify the last entry in the Route, i.e. (B). Your first proposal in section 2 prohibits such behavior: "[...] an element [...] MUST NOT modify or remove subsequent Route header field values." Is this restriction intended also for such cases or could we relax it to allow modifying of the last entry in Route? Would marking the last Route entry as the intended destination (and allow modifying of such only) solve this issue? Greetings, Bernie PS: Some Typos: - section 5.5, F7-F12: s/Contact: sip:jbj@212.28.214.227/Contact: sip:jbj@212.28.214.228/ - section 5.5. F3/F4: - Shouldn't maddr in F4 contain a different IP-address than in F3? - Maybe add a FQDN <-> IP mapping table to ease the understanding of the examples. - section 5.8: s/senting/sending/ >-----Original Message----- >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: 14. January 2002 20:58 >To: 'sip@ietf.org' >Subject: [Sip] Attention - comment on Loose Routing draft > > >The draft below contains the resolution to a large >set of open issues around processing of the Route header, >preloaded routes, and the use of default outbound proxies. >The plan is to modify bis to reflect these proposals. > >Please review it as soon as you can and comment if you >see real problems. Silence will be taken as consent. > >RjS > >> -----Original Message----- >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >> Sent: Thursday, January 10, 2002 10:46 PM >> To: 'sip@ietf.org' >> Subject: [Sip] Loose Routing draft >> >> >> I just submitted a draft refining the post I sent >> out after IETF52 on the loose routing proposal. >> >> Until it appears in the archive, you can find it at >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt >> or >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html >> >> >> RjS >> >> _______________________________________________ >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 15 10:59:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00203 for ; Tue, 15 Jan 2002 10:59:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA11328 for sip-archive@odin.ietf.org; Tue, 15 Jan 2002 10:59:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10526; Tue, 15 Jan 2002 10:30:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10482 for ; Tue, 15 Jan 2002 10:30:21 -0500 (EST) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29028 for ; Tue, 15 Jan 2002 10:30:18 -0500 (EST) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24794 for ; Tue, 15 Jan 2002 10:28:55 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24780 for ; Tue, 15 Jan 2002 10:28:54 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Date: Tue, 15 Jan 2002 08:30:51 -0700 Message-ID: Thread-Topic: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Thread-Index: AcGdwmoin7U7joNdT32UKaj6W7+tlAAFXJWg From: "Zmolek, Andrew (Andrew)" To: "Neil Deason" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA10483 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit If loop detection is not reasonable, it may be still reasonable to make loop avoidance a topic in the forthcoming implementer's guide. Our existing PBX product, for instance, initiates a 15-second timer when forwarding. New calls received within that period are treated as if the forwarding request were not in place, thus preventing a form of deadly embrace between the local phone switch and the PBX across all remaining trunks. I would think a similar solution is applicable to SIP servers, but as an implementation detail. --Andy Zmolek Technology & Standards Engineer CTO Standards Avaya Inc. zmolek@avaya.com +1 720 444 4001 -----Original Message----- From: Neil Deason [mailto:ndeason@ubiquity.net] Sent: Tuesday, January 15, 2002 5:31 AM To: sip@ietf.org Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers > Christer Holmberg wrote: > > > Hi, > > > > > >>Anyone for deprecating loop detection? A proxy that doesn't > do it would > >>have to insert max-forwards if not already present, that is the > >> > > penalty. > > > >>We also need a minimum value for Max-Forwards, something like 20 is > >>more than sufficient, I think. > >> > > > > Do we need to specify a minimum value in the spec? I think > the value is > > something which is very dependent on the size and > architechture of the > > network, and should be configurable. > > > That is a recipe for disaster. Big disasters. > > Remember, calls go between domains that are frequently not in > any kind > of business relationship. I have no way of knowing what kind > of network > is downstream. So, we choose a value which is sufficiently large to > cover all realistic cases. Having it configurable means it could be > right today, but wrong tomorrow. Shall I have all my > customers support > calls get forwarded to you, Christer, so you can explain why a call > yesterday won't work today because a different network provider > installed a new proxy? If we have no way of knowing what network SIP will run over now, or in the future, what is guaranteed to always be a large enough number? Though this will create inefficient network usage. It is unclear how B2BUAs would interact with Max-Forwards headers as they pass through their UAS|UAC state machine. RFC2543 UAs may (i.e. will) not typically add in Max-Forwards RFC 2543 Proxies certainly wont add it where omitted. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 15 13:22:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08175 for ; Tue, 15 Jan 2002 13:22:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA16880 for sip-archive@odin.ietf.org; Tue, 15 Jan 2002 13:22:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15396; Tue, 15 Jan 2002 12:44:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15370 for ; Tue, 15 Jan 2002 12:44:17 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06827 for ; Tue, 15 Jan 2002 12:44:15 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GPZ00901QKSOK@firewall.wcom.com> for sip@ietf.org; Tue, 15 Jan 2002 17:43:40 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GPZ0089GQKSYQ@firewall.wcom.com>; Tue, 15 Jan 2002 17:43:40 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GPZ00M01QKJKY@pmismtp04.wcomnet.com>; Tue, 15 Jan 2002 17:43:39 +0000 (GMT) Received: from ajohnston ([166.44.56.225]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GPZ00IIHQKD3I@pmismtp04.wcomnet.com>; Tue, 15 Jan 2002 17:43:27 +0000 (GMT) Date: Tue, 15 Jan 2002 11:43:16 -0600 From: Alan Johnston Subject: RE: [Sip] [bis-05] Table 3 and the Supported header In-reply-to: <475FF955A05DD411980D00508B6D5FB0042468F7@en0033exch001u.uk.lucent.com> To: "'Drage, Keith (Keith)'" , sip@ietf.org Message-id: <006e01c19dec$1de627f0$b4202aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Keith, The next version of bis will define that a blank in the "where" column means the header may be present in both requests and responses, which I believe is true for Supported. I suppose that it should say "r" in the "proxy" column. The noting of "r" in this column is a leftover from when 2543 had a defined mechanism for encrypting selected headers. Since this mechanism is now gone, perhaps this label is not needed. On the other hand, it doesn't hurt anything. "g" for General header is no longer used and has been removed from Tables 2 and 3. Thanks, Alan Johnston sip:alan@siptest.wcom.com -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Drage, Keith (Keith) Sent: Tuesday, January 15, 2002 8:26 AM To: sip@ietf.org Subject: [Sip] [bis-05] Table 3 and the Supported header In Table 3 of the bis-05 draft, the Supported header is included. In this table the entry for "Where" is missing. In addition, the entry for "proxy" is blank. The timer draft contains procedures for proxies looking at the contents of the Supported header in a request, to see if the "timer" option-tag is included. I therefore assume that at least for requests, there should be an "r" in the proxy column. If the "r" only applies for requests, then this header needs to be split into two rows, identified in the Where column by "R" and "r" respectively. If the behaviour is the same for both request and response, then the Where column should contain the value "g". Incidently, while the value "g" is used in this table, it is not defined in the key at the start of the table. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 15 14:50:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11262 for ; Tue, 15 Jan 2002 14:50:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA20189 for sip-archive@odin.ietf.org; Tue, 15 Jan 2002 14:50:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19265; Tue, 15 Jan 2002 14:26:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19233 for ; Tue, 15 Jan 2002 14:25:58 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10519 for ; Tue, 15 Jan 2002 14:25:55 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0FJNbkN012100; Tue, 15 Jan 2002 14:23:37 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 15 Jan 2002 14:25:23 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E989@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Honeisen Bernhard (NET/Helsinki)'" , sip@ietf.org Subject: RE: [Sip] Attention - comment on Loose Routing draft Date: Tue, 15 Jan 2002 14:25:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The restriction against modifying or removing Route header field values beyond the topmost one is needed to ensure that the resources placed in the Route are eventually visited. Without something like it, a policy of "remove and ignore all Route headers" would be valid - something we don't want. If a resource appears in a Route header the request must eventually reach that resource. The problem with X reaching into the stack and touching the B entry is that X doesn't necessarily know what Y was going to do. The sender of the request may have really intended for B to process the request based on the output of Y. So, just like it would be bad for X to decide the request doesn't _really_ need to go to Y, it would be bad for X to decide the request doesn't really need to go to B. So, the question I'm taking from this is does the recommendation to put the intended destination at the end of the route set effectivly prevent retargeting of the request before the owner of that last element is reached? It looks like it does if the request encounters a strict router on the path (such an encounter is exactly what motivated the recommendation). It would help in exploring this if you could provide details of a specific instance of the scenario you have in mind. RjS > Consider a situation, where a request is directed > to (B) and two service elements (X) and (Y) have > to be visited before. > (X) performs a service, which replaces the intended > destination URL, i.e. (B), whereas (Y) executes > some feature, which depends on the output of (X). > > When the request arrives at (X), the R-URI / Route > could look like: > - R-URI: > - Route: , > (The intended destination has been appended earlier > to Route as per section 5.2 in your I/D) > > How can (X) now apply the destination URL relacing feature? > My first guess was, that (X) would modify the last entry > in the Route, i.e. (B). > > Your first proposal in section 2 prohibits such behavior: > "[...] an element [...] MUST NOT modify or remove > subsequent Route header field values." > > Is this restriction intended also for such cases or could > we relax it to allow modifying of the last entry in Route? > Would marking the last Route entry as the intended > destination (and allow modifying of such only) solve > this issue? > > Greetings, > Bernie > > > PS: Some Typos: > > - section 5.5, F7-F12: > s/Contact: sip:jbj@212.28.214.227/Contact: sip:jbj@212.28.214.228/ > > - section 5.5. F3/F4: > - Shouldn't maddr in F4 contain a different IP-address > than in F3? > - Maybe add a FQDN <-> IP mapping table to ease > the understanding of the examples. > > - section 5.8: > s/senting/sending/ > > > > >-----Original Message----- > >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > >Sent: 14. January 2002 20:58 > >To: 'sip@ietf.org' > >Subject: [Sip] Attention - comment on Loose Routing draft > > > > > >The draft below contains the resolution to a large > >set of open issues around processing of the Route header, > >preloaded routes, and the use of default outbound proxies. > >The plan is to modify bis to reflect these proposals. > > > >Please review it as soon as you can and comment if you > >see real problems. Silence will be taken as consent. > > > >RjS > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > >> Sent: Thursday, January 10, 2002 10:46 PM > >> To: 'sip@ietf.org' > >> Subject: [Sip] Loose Routing draft > >> > >> > >> I just submitted a draft refining the post I sent > >> out after IETF52 on the loose routing proposal. > >> > >> Until it appears in the archive, you can find it at > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt > >> or > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html >> >> >> RjS >> >> _______________________________________________ >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 15 22:25:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19837 for ; Tue, 15 Jan 2002 22:25:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA04653 for sip-archive@odin.ietf.org; Tue, 15 Jan 2002 22:25:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03414; Tue, 15 Jan 2002 21:45:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA03382 for ; Tue, 15 Jan 2002 21:45:34 -0500 (EST) Received: from hssblrmail.hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19495 for ; Tue, 15 Jan 2002 21:45:28 -0500 (EST) From: sshetti@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hssblrmail.hss.hns.com (8.11.2/8.11.2) with SMTP id g0G2Y9910033; Wed, 16 Jan 2002 08:04:10 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B43.000E5932 ; Wed, 16 Jan 2002 08:06:43 +0530 X-Lotus-FromDomain: HSSBLR To: Alan Johnston , sip@ietf.org Message-ID: <65256B43.000E57CD.00@sampark.hss.hns.com> Date: Wed, 16 Jan 2002 08:06:38 +0530 Subject: [Sip] [bis-05] Table 3 and the user-agent header Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, under changes made to bis-05 it is stated that user-agent header is now a request header in Table 3. But under the table it is still left blank. does it mean that "user-agent" header remains general header, or its going to be request header. -Shetti _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 15 23:52:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22108 for ; Tue, 15 Jan 2002 23:52:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA07108 for sip-archive@odin.ietf.org; Tue, 15 Jan 2002 23:52:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06456; Tue, 15 Jan 2002 23:21:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06425 for ; Tue, 15 Jan 2002 23:21:48 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21355 for ; Tue, 15 Jan 2002 23:21:44 -0500 (EST) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g0G4Lk627059; Tue, 15 Jan 2002 23:21:46 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time Date: Tue, 15 Jan 2002 23:24:07 -0500 Message-ID: <000901c19e45$a4456d70$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E987@DYN-TX-EXCH-001.dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Eventually, someone will find something > where changing 1 minute to 1 hour would > be just as damaging. That is a two way street. A registrar with 100,000 subscribers might not desire to accommodate its users extending contact expirations through registrations every 30 seconds. However I guess this gets into an issue of billing for capacity-usage. > > A reasonable argument. The point of extending the > > URI lifetime was not to do this kind of thing. It > > is meant as a defensive mechanism for the server > > to say basically that it's timer resolution is greater > > than what you are attempting. I think that is a > > reasonable thing to say. If you want to accomplish > > this through a 4xx response, that is actually fine > > with me. I would like an explicit response code > > and header (akin to Retry-After) that would allow > > the server to reject the registration and suggest > > a more suitable resolution. > > This is a better direction to go. The problem with returning a new error response is that non-bis compliant UAC's would reduce the response to 400. Thus it might actually produce more registrations and restrict the user from receiving calls until customer support communicates what the timer should be. The 403 with Expires or a new header could potentially be used to avoid such a situation. The UAC could automatically adjust the expiration or at least communicate the minimum to the user. The advantage is that older UACs SHOULD NOT retry the REGISTER without modifying something (excluding authorization) associated with the REGISTER request; changing the expiration value should produce another registration try. Taking it one step further, we could add a new parameter to Contact which could indicate that the UAC currently does not intend to refresh the contact beyond the indicated expires value. This should calm nervous registrars to start allowing short expiration values under the pre-text that a 403 would be honored if such a contact gets refreshed too often. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 00:50:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23031 for ; Wed, 16 Jan 2002 00:50:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA08560 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 00:50:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07924; Wed, 16 Jan 2002 00:22:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA07897 for ; Wed, 16 Jan 2002 00:22:40 -0500 (EST) Received: from hssblrmail.hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22328 for ; Wed, 16 Jan 2002 00:22:36 -0500 (EST) From: pnath@hss.hns.com Received: from sampark.hss.hns.com ([192.168.17.10]) by hssblrmail.hss.hns.com (8.11.2/8.11.2) with SMTP id g0G5AP910539; Wed, 16 Jan 2002 10:40:26 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256B43.001CA974 ; Wed, 16 Jan 2002 10:43:03 +0530 X-Lotus-FromDomain: HSSBLR To: Jonathan Rosenberg cc: sip@ietf.org Message-ID: <65256B43.001CA859.00@sampark.hss.hns.com> Date: Wed, 16 Jan 2002 10:43:00 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] bis-06 release date? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi , > There has been little comment on the proposal to deprecate loop > detection; one email in favor, and a few questions. Without any > additional comment it will be removed from bis-06. Just curious... When is the rfc2543 bis06 expected to be out ? Will it be after closure of all remaining open issues? Regds, Pankaj Nath Hughes Software Systems, Bangalore _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 04:32:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03253 for ; Wed, 16 Jan 2002 04:32:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23773 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 04:32:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22926; Wed, 16 Jan 2002 04:01:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22895 for ; Wed, 16 Jan 2002 04:01:18 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02982 for ; Wed, 16 Jan 2002 04:01:10 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0G90su08114 for ; Wed, 16 Jan 2002 11:00:54 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Jan 2002 11:01:07 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 16 Jan 2002 11:01:06 +0200 content-class: urn:content-classes:message Subject: RE: [Sip] Attention - comment on Loose Routing draft Date: Wed, 16 Jan 2002 11:01:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [Sip] Attention - comment on Loose Routing draft Thread-Index: AcGd+mOTqNDH8RBYRg+eyqKJideAAgAZzi1A From: "Honeisen Bernhard (NET/Helsinki)" To: "'ext Robert Sparks'" Cc: X-OriginalArrivalTime: 16 Jan 2002 09:01:06.0879 (UTC) FILETIME=[555B54F0:01C19E6C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA22896 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Robert! My comments inline. >The restriction against modifying or removing Route header >field values beyond the topmost one is needed to ensure that >the resources placed in the Route are eventually visited. >Without something like it, a policy of "remove and ignore >all Route headers" would be valid - something we don't want. >If a resource appears in a Route header the request must >eventually reach that resource. No problem with this. >The problem with X reaching into the stack and touching >the B entry is that X doesn't necessarily know what Y >was going to do. The sender of the request may have >really intended for B to process the request based on >the output of Y. So, just like it would be bad for X >to decide the request doesn't _really_ need to go to Y, >it would be bad for X to decide the request doesn't >really need to go to B. > >So, the question I'm taking from this is does the recommendation >to put the intended destination at the end of the route set >effectivly prevent retargeting of the request before the owner >of that last element is reached? It looks like it does if the >request encounters a strict router on the path (such an encounter >is exactly what motivated the recommendation). The recommendation to put the intended destination at the end of the route set as such is rather sensible. We need such functionality, if we are pre-loading Route headers AND routing might be strict. Thus, this is an issue even with the current (as so far specified in RFC2543/bis) approach. I see your point, that if proxies can wildly change the Route set, we are ending up in a mess. Therefore, I was thinking, whether we should somehow mark the Route header entry, which points to a intended detination and AND , X can perform the retargeting service. Example: INVITE Route: , ; intended-destination (if the intended-destination tag present, we can modify it) The problem now is maybe, how the earlier element knows, when to mark to last Route header. Or would it be enough to mandate (or recommend) such marking, if we are adding the intended destination at the end of the route set (5.2). >It would help in exploring this if you could provide details >of a specific instance of the scenario you have in mind. I tried to generalize the example as much as possible. (X) could be a service: find best destination UAS depending on the time of the day, etc. (Y) could be a statistics service, which logs all outgoing calls, right before they leave my network The real example comes from 3GPP, where we have a set of Application Servers (AS) to traverse and we don't know, what they are doing. But retargeting a request is a likely service. In 3GPP it could look like (some network elements are skipped for the sake of brevity; A is UAC, B is UAS): - - - - At the first visit of , we get a set of AS to traverse (in this example one). After the AS, the request has to be routed back to the S-CSCF. I had in mind, that the pre-loads the route as follows: INVITE Route: , And if has to be retargeted, would do it in the last Route header. Another example could look like: - - - - - - INVITE Route: , , , Note: The detailed routing mechanisms between and are currently beeing standardized in 3GPP and the preferred way is to do it in line with SIP. Greetings, Bernie >RjS > >> Consider a situation, where a request is directed >> to (B) and two service elements (X) and (Y) have >> to be visited before. >> (X) performs a service, which replaces the intended >> destination URL, i.e. (B), whereas (Y) executes >> some feature, which depends on the output of (X). >> >> When the request arrives at (X), the R-URI / Route >> could look like: >> - R-URI: >> - Route: , >> (The intended destination has been appended earlier >> to Route as per section 5.2 in your I/D) >> >> How can (X) now apply the destination URL relacing feature? >> My first guess was, that (X) would modify the last entry >> in the Route, i.e. (B). >> >> Your first proposal in section 2 prohibits such behavior: >> "[...] an element [...] MUST NOT modify or remove >> subsequent Route header field values." >> >> Is this restriction intended also for such cases or could >> we relax it to allow modifying of the last entry in Route? >> Would marking the last Route entry as the intended >> destination (and allow modifying of such only) solve >> this issue? >> >> Greetings, >> Bernie >> >> >> PS: Some Typos: >> >> - section 5.5, F7-F12: >> s/Contact: sip:jbj@212.28.214.227/Contact: sip:jbj@212.28.214.228/ >> >> - section 5.5. F3/F4: >> - Shouldn't maddr in F4 contain a different IP-address >> than in F3? >> - Maybe add a FQDN <-> IP mapping table to ease >> the understanding of the examples. >> >> - section 5.8: >> s/senting/sending/ >> >> >> >> >-----Original Message----- >> >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] >> >Sent: 14. January 2002 20:58 >> >To: 'sip@ietf.org' >> >Subject: [Sip] Attention - comment on Loose Routing draft >> > >> > >> >The draft below contains the resolution to a large >> >set of open issues around processing of the Route header, >> >preloaded routes, and the use of default outbound proxies. >> >The plan is to modify bis to reflect these proposals. >> > >> >Please review it as soon as you can and comment if you >> >see real problems. Silence will be taken as consent. >> > >> >RjS >> > >> >> -----Original Message----- >> >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >> >> Sent: Thursday, January 10, 2002 10:46 PM >> >> To: 'sip@ietf.org' >> >> Subject: [Sip] Loose Routing draft >> >> >> >> >> >> I just submitted a draft refining the post I sent >> >> out after IETF52 on the loose routing proposal. >> >> >> >> Until it appears in the archive, you can find it at >> >> >http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00 .txt > >> or > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html >> >> >> RjS >> >> _______________________________________________ >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 10:02:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10163 for ; Wed, 16 Jan 2002 10:02:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04437 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 10:02:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02970; Wed, 16 Jan 2002 09:33:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA02943 for ; Wed, 16 Jan 2002 09:33:25 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08829 for ; Wed, 16 Jan 2002 09:33:21 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0GEWqA21124 for ; Wed, 16 Jan 2002 09:32:52 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Jan 2002 14:32:51 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC3553@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" , sip@ietf.org, "'Alan Johnston'" Subject: RE: [Sip] [bis-05] Table 3 and the Supported header Date: Wed, 16 Jan 2002 14:32:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org See below many thanks for the response Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Alan Johnston[SMTP:alan.johnston@wcom.com] > Sent: 15 January 2002 17:43 > To: 'Drage, Keith (Keith)'; sip@ietf.org > Subject: RE: [Sip] [bis-05] Table 3 and the Supported header > > Keith, > > The next version of bis will define that a blank in the "where" column > means the header may be present in both requests and responses, which I > believe is true for Supported. > > I suppose that it should say "r" in the "proxy" column. The noting of > "r" in this column is a leftover from when 2543 had a defined mechanism > for encrypting selected headers. Since this mechanism is now gone, > perhaps this label is not needed. On the other hand, it doesn't hurt > anything. > I am looking for consistency, so either we should have it, or not have it. Certainly if we believe that proxies can read all headers, we should remove "r" as it will be a source of future confusion. Either that or we should consistently use it. Certainly the current bis-05 text: r: indicates that a proxy must be be able to read the header. Headers that need to be read cannot be encrypted. does not correspond to your statements and needs to be amended. > "g" for General header is no longer used and has been removed from > Tables 2 and 3. > I am looking for consistency, so I am happy with leaving the "where" column blank so long as the "g" has been removed from elsewhere in the table. There was at least one instance in bis-05 > Thanks, > Alan Johnston > sip:alan@siptest.wcom.com > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Drage, > Keith (Keith) > Sent: Tuesday, January 15, 2002 8:26 AM > To: sip@ietf.org > Subject: [Sip] [bis-05] Table 3 and the Supported header > > In Table 3 of the bis-05 draft, the Supported header is included. > > In this table the entry for "Where" is missing. > > In addition, the entry for "proxy" is blank. > > The timer draft contains procedures for proxies looking at the contents > of > the Supported header in a request, to see if the "timer" option-tag is > included. I therefore assume that at least for requests, there should be > an > "r" in the proxy column. > > If the "r" only applies for requests, then this header needs to be split > into two rows, identified in the Where column by "R" and "r" > respectively. > If the behaviour is the same for both request and response, then the > Where > column should contain the value "g". > > Incidently, while the value "g" is used in this table, it is not defined > in > the key at the start of the table. > > Keith > > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 10:48:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11880 for ; Wed, 16 Jan 2002 10:48:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06248 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 10:48:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04869; Wed, 16 Jan 2002 10:18:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04838 for ; Wed, 16 Jan 2002 10:18:16 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10722 for ; Wed, 16 Jan 2002 10:18:12 -0500 (EST) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id g0GGLkM30234; Wed, 16 Jan 2002 10:21:46 -0600 Message-ID: <000801c19ea0$ebe7fd90$2164a8c0@flak> From: "Dean Willis" To: Cc: "Rohan Mahy" , , , "Allison Mankin" Date: Wed, 16 Jan 2002 05:18:57 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Sip] "Replaces" header work on SIP charter Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The ADs have approved completing work on the Replaces header under the "call control" element of the SIP WG charter. The current working document is draft-ietf-sip-replaces-00.txt, which should be announced soon, and which I will place in the supplemental web site drafts archive the next time I get a broadband connection -- web editing over GSM is a bit tedious, not to mention expensive at $3/minute. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 11:17:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12831 for ; Wed, 16 Jan 2002 11:17:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07426 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 11:17:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06222; Wed, 16 Jan 2002 10:47:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06195 for ; Wed, 16 Jan 2002 10:47:45 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11850 for ; Wed, 16 Jan 2002 10:47:42 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0GFjNkN017458; Wed, 16 Jan 2002 10:45:24 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Jan 2002 10:47:10 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E98F@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Honeisen Bernhard (NET/Helsinki)'" , Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] Attention - comment on Loose Routing draft Date: Wed, 16 Jan 2002 10:46:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Current strict-routing renders the request-URI of a request containing a Route header impotent. On reflection, looseroute-00 suggests that you could use it anyhow and as long as everyone played nice (i.e. you did not encounter any strict routers) the request-URI of a request containing Route headers could have meaning. However, it introduced a suggestion for protection against an element that doesn't play nice that defeats the whole point, at least with the suggested routing mechanism. So - we can attack either the protection mechanism or the routing mechanism. The direction you are suggesting can be made to work. It basically says that the Request-URI is meaningless in the presence of Route headers because legacy strict-routers might exist, so lets just replace its functionality with some other peice of the message. It would define a "real" request-URI. If we were to go down this path, making it a new header rather than a specially tagged last Route element would be better - it really has a different meaning than Route and forcing elements to find the last value of a header field to do their normal job is something we are learning to avoid (it generally becomes an O(n^2) requirement on the overall system). Unfortunately, that removes the protection against strict-routers that having the intended destination in the last Route would provide. Several people have suggested the alternative of using Proxy-Require and further restricting the loose route policy to say the output Request-URI must always reflect the intended destination (possibly after retargetting). The problem with this kind of proposal (beyond its tendency to become Proxy-Require:do-what-i-mean) is it doesn't fail well when the ultimate destination is behind a strict-router. It becomes impossible to reach that destination _and_ invoke services using the routing mechanism - you have to pick one. Now, we could remove the suggestion to add the intended destination as the last route element, and accept the potential failure induced by running into a strict-router in between the elements on the Route set (we don't get failure if the strict-router is encountered after the Route set is exhausted). Is that kind of failure really likely to occur. Certainly not within domains of control - the only scenarios to study are those where you have multiple domains of control on the route set (visiting and home services for example) and there might be a strict router between those domains. At the moment, I'm leaning towards the last. The proposal would be to remove the suggestion to add the intended destination to the last route and point out where legacy strict routers will introduce failure. This gets us back to carrying the targetting information in the Request-URI, where it belongs. RjS > >The restriction against modifying or removing Route header > >field values beyond the topmost one is needed to ensure that > >the resources placed in the Route are eventually visited. > >Without something like it, a policy of "remove and ignore > >all Route headers" would be valid - something we don't want. > >If a resource appears in a Route header the request must > >eventually reach that resource. > > No problem with this. > > >The problem with X reaching into the stack and touching > >the B entry is that X doesn't necessarily know what Y > >was going to do. The sender of the request may have > >really intended for B to process the request based on > >the output of Y. So, just like it would be bad for X > >to decide the request doesn't _really_ need to go to Y, > >it would be bad for X to decide the request doesn't > >really need to go to B. > > > >So, the question I'm taking from this is does the recommendation > >to put the intended destination at the end of the route set > >effectivly prevent retargeting of the request before the owner > >of that last element is reached? It looks like it does if the > >request encounters a strict router on the path (such an encounter > >is exactly what motivated the recommendation). > > The recommendation to put the intended destination at the end > of the route set as such is rather sensible. > We need such functionality, if we are pre-loading Route headers > AND routing might be strict. > Thus, this is an issue even with the current (as so far > specified in RFC2543/bis) approach. > > I see your point, that if proxies can wildly change the > Route set, we are ending up in a mess. > Therefore, I was thinking, whether we should somehow mark > the Route header entry, which points to a intended detination > and AND Route entry>, X can perform the retargeting service. > > Example: > > INVITE > Route: , > ; intended-destination > > (if the intended-destination tag present, we can modify it) > > The problem now is maybe, how the earlier element knows, when > to mark to last Route header. Or would it be enough to mandate > (or recommend) such marking, if we are adding the intended > destination at the end of the route set (5.2). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 11:42:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13610 for ; Wed, 16 Jan 2002 11:42:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08726 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 11:42:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07398; Wed, 16 Jan 2002 11:16:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07295 for ; Wed, 16 Jan 2002 11:15:57 -0500 (EST) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12754 for ; Wed, 16 Jan 2002 11:15:54 -0500 (EST) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-7.04) id A73B52F201C2; Wed, 16 Jan 2002 11:15:55 -0500 Message-ID: <004101c19ea8$c0da2260$2300000a@acmepacket.com> From: "Bob Penfield" To: "Drage, Keith \(Keith\)" , , "'Alan Johnston'" References: <475FF955A05DD411980D00508B6D5FB001AC3553@en0033exch001u.uk.lucent.com> Subject: Re: [Sip] [bis-05] Table 3 and the Supported header Date: Wed, 16 Jan 2002 11:13:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I don't think it would be a good idea to remove "r" from the "where" column in table 3. In spite of the fact that PGP encryption of headers has been deprecated, there have been some proposals to put hashed values into headers (e.g. Via recently). The base spec needs to clearly indicate those headers that proxies must be able to read so they should not be mucked with by endpoints or other intermediaries. cheers, (-:bob ----- Original Message ----- From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" ; ; "'Alan Johnston'" Sent: Wednesday, January 16, 2002 9:32 AM Subject: RE: [Sip] [bis-05] Table 3 and the Supported header > See below > > many thanks for the response > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Alan Johnston[SMTP:alan.johnston@wcom.com] > > Sent: 15 January 2002 17:43 > > To: 'Drage, Keith (Keith)'; sip@ietf.org > > Subject: RE: [Sip] [bis-05] Table 3 and the Supported header > > > > Keith, > > > > The next version of bis will define that a blank in the "where" column > > means the header may be present in both requests and responses, which I > > believe is true for Supported. > > > > I suppose that it should say "r" in the "proxy" column. The noting of > > "r" in this column is a leftover from when 2543 had a defined mechanism > > for encrypting selected headers. Since this mechanism is now gone, > > perhaps this label is not needed. On the other hand, it doesn't hurt > > anything. > > > I am looking for consistency, so either we should have it, or not have it. > Certainly if we believe that proxies can read all headers, we should remove > "r" as it will be a source of future confusion. Either that or we should > consistently use it. > > Certainly the current bis-05 text: > > r: indicates that a proxy must be be able to read the header. > Headers that need to be read cannot be encrypted. > > does not correspond to your statements and needs to be amended. > > > "g" for General header is no longer used and has been removed from > > Tables 2 and 3. > > > I am looking for consistency, so I am happy with leaving the "where" column > blank so long as the "g" has been removed from elsewhere in the table. There > was at least one instance in bis-05 > > > Thanks, > > Alan Johnston > > sip:alan@siptest.wcom.com > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Drage, > > Keith (Keith) > > Sent: Tuesday, January 15, 2002 8:26 AM > > To: sip@ietf.org > > Subject: [Sip] [bis-05] Table 3 and the Supported header > > > > In Table 3 of the bis-05 draft, the Supported header is included. > > > > In this table the entry for "Where" is missing. > > > > In addition, the entry for "proxy" is blank. > > > > The timer draft contains procedures for proxies looking at the contents > > of > > the Supported header in a request, to see if the "timer" option-tag is > > included. I therefore assume that at least for requests, there should be > > an > > "r" in the proxy column. > > > > If the "r" only applies for requests, then this header needs to be split > > into two rows, identified in the Where column by "R" and "r" > > respectively. > > If the behaviour is the same for both request and response, then the > > Where > > column should contain the value "g". > > > > Incidently, while the value "g" is used in this table, it is not defined > > in > > the key at the start of the table. > > > > Keith > > > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.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 daemon@optimus.ietf.org Wed Jan 16 11:49:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13746 for ; Wed, 16 Jan 2002 11:49:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08878 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 11:49:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07715; Wed, 16 Jan 2002 11:24:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07683 for ; Wed, 16 Jan 2002 11:24:11 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13007 for ; Wed, 16 Jan 2002 11:24:07 -0500 (EST) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0GGNWF28271; Wed, 16 Jan 2002 08:23:32 -0800 (PST) Date: Wed, 16 Jan 2002 08:23:31 -0800 (PST) From: Rohan Mahy To: cc: , , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] draft-ietf-sip-replaces-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Folks, Until it appears in the archive, the replaces draft is available at: ftp://ftpeng.cisco.com/rmahy/draft-ietf-sip-replaces-00.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 daemon@optimus.ietf.org Wed Jan 16 14:32:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18576 for ; Wed, 16 Jan 2002 14:32:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16904 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 14:32:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15303; Wed, 16 Jan 2002 14:00:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15272 for ; Wed, 16 Jan 2002 14:00:35 -0500 (EST) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17700 for ; Wed, 16 Jan 2002 14:00:31 -0500 (EST) Received: from adsl-64-169-17-213.dsl.snfc21.pacbell.net (HELO rwc-jfmule01.yahoo.com) (64.169.17.213) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Jan 2002 19:00:29 -0000 Message-Id: <5.1.0.14.2.20020116105243.02718700@pop.mail.yahoo.com> X-Sender: jfmule@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 16 Jan 2002 10:59:36 -0800 To: sip@ietf.org From: Jean-Francois Mule Cc: klingle@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Sip] SIP RFC2543: 1 new MIB object to deal with Expires header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Also, as per Tom Taylor's comments on sip-mib-03, we are adding an object in the sip-common mib to deal with the Expires header. 2 quick questions: To be precise, the Expires is only allowed in REGISTER (optional), INVITE (optional), and in responses like 302, 504 (optional). We have defined a new object for the 2 method settings for INVITE and REGISTER and also allowed any response code settings (to cover 302, 504 and may be some future ones). - any comments? Default value (see prior posting related to bis-05 nits) - shall 2**32-1 be considered as default value? Jean-Francois. jfmule@packetizer.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 14:32:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18570 for ; Wed, 16 Jan 2002 14:32:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16890 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 14:32:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14863; Wed, 16 Jan 2002 13:55:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14835 for ; Wed, 16 Jan 2002 13:55:00 -0500 (EST) Received: from server640.peel5.com ([216.28.47.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17533 for ; Wed, 16 Jan 2002 13:54:54 -0500 (EST) Received: from adsl-64-169-17-213.dsl.snfc21.pacbell.net ([64.169.17.213] helo=rwc-jfmule01.packetizer.com) by server640.peel5.com with esmtp (Exim 3.34 #1) id 16QvCy-0007i1-00; Wed, 16 Jan 2002 13:54:49 -0500 Message-Id: <5.1.0.14.2.20020116101102.026c9360@pop.mail.yahoo.com> X-Sender: jfmule@mail.packetizer.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 16 Jan 2002 10:53:56 -0800 To: sip@ietf.org From: Jean-Francois Mule Cc: klingle@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server640.peel5.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - packetizer.com Subject: [Sip] minor editorial nits in SIP RFC2543 bis-05: Expires header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -- minor editorial comment #1 In section 23 of RFC2543 bis-05, it is stated that the "Expires" header may be used in 302, 504 (at least those 2 are explicitly mentioned). => in section 22, this should be reflected in Table 2 in the column named "where". -- minor editorial comment #2 In section 22.19, the spec could gain in clarity by adding an additional sentence or two to specify the behavior of the UAS/proxy in 2 cases: (a) when the method definition does not make any mention of Expires (see previous thread on REFER method and RjS' response) (b) when the header is omitted (which is equivalent to putting 2**32-1 as the Expires value). Jean-Francois. jfmule@packetizer.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 15:59:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20790 for ; Wed, 16 Jan 2002 15:59:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19104 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 15:59:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18136; Wed, 16 Jan 2002 15:25:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18106 for ; Wed, 16 Jan 2002 15:25:00 -0500 (EST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20192 for ; Wed, 16 Jan 2002 15:24:55 -0500 (EST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA00205 for ; Wed, 16 Jan 2002 14:24:28 -0600 (CST) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g0GKORm23496 for ; Wed, 16 Jan 2002 14:24:27 -0600 (CST) Received: from ssd.usa.alcatel.com (sun3267.ssd.usa.alcatel.com [143.209.150.106]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id g0GKO6G01711 for ; Wed, 16 Jan 2002 14:24:06 -0600 (CST) Message-ID: <3C45E165.F328412C@ssd.usa.alcatel.com> Date: Wed, 16 Jan 2002 14:24:06 -0600 From: "Carlos F. Gonzalez De Requena" X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] confirm 922915 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit -- Alcatel USA, Inc. Internet: @ssd.usa.alcatel.com 1000 Coit Road, Plano, Texas 75075 ******* The opinions expressed are not those of Alcatel USA, Inc. ******* _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 17:54:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22920 for ; Wed, 16 Jan 2002 17:54:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23526 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 17:54:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22245; Wed, 16 Jan 2002 17:22:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22214 for ; Wed, 16 Jan 2002 17:22:42 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22256 for ; Wed, 16 Jan 2002 17:22:38 -0500 (EST) Received: from madrid.ericsson.se (madrid.es.eu.ericsson.se [159.107.53.220]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0GMMeJ17225 for ; Wed, 16 Jan 2002 23:22:40 +0100 (MET) Received: from lmf.ericsson.se by madrid.ericsson.se (SMI-8.6/SMI-SVR4) id XAA26681; Wed, 16 Jan 2002 23:22:34 +0100 Message-ID: <3C45FD38.3DFA3AE8@lmf.ericsson.se> Date: Thu, 17 Jan 2002 00:22:48 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Question of looseroute draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, A cople of questions/clarifications on the looseroute draft. First, assume that a UAC inserts a preloaded route in the initial INVITE request, and the message is then received by a proxy. Now, for whatever policy/management/whatever reason the proxy is not allowed, or does not want to, forward the request to the next node in the node. Should there be a specific response code to indicate that to the client, or can an existing code be used? Also, would it be useful to somehow in the response include the Route header which caused the error response, so that the client can (if possible) try another route (if available)? Second, just to clarify, my understanding of the draft is that it is allowed for a proxy to insert a preloaded route in a request it receives from a client, as long as it doesn't remove/modify any possible Route headers in the received message? The UAC may have no idea which proxies, ie which route, the request shall "visit", so... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 17:59:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23077 for ; Wed, 16 Jan 2002 17:59:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23672 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 17:59:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21973; Wed, 16 Jan 2002 17:14:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21943 for ; Wed, 16 Jan 2002 17:14:56 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22111 for ; Wed, 16 Jan 2002 17:14:52 -0500 (EST) Received: from madrid.ericsson.se (madrid.es.eu.ericsson.se [159.107.53.220]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0GMEsJ15853; Wed, 16 Jan 2002 23:14:54 +0100 (MET) Received: from lmf.ericsson.se by madrid.ericsson.se (SMI-8.6/SMI-SVR4) id XAA26351; Wed, 16 Jan 2002 23:14:44 +0100 Message-ID: <3C45FB62.376ABB5E@lmf.ericsson.se> Date: Thu, 17 Jan 2002 00:14:58 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: "'bernhard.honeisen@nokia.com'" , sip@ietf.org Subject: Re: [Sip] Loose Routing draft References: <9BF66EBF6BEFD942915B4D4D45C051F338E95A@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Is there a requirement, that loose routing is needed in >>subsequent requests? >There are people that want to be able to do this. I guess it shall be mentioned that it MUST be used for CANCEL (to the INVITE request). Does anything need to be said about ACK, or can it be treated like any "subsequent request"? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 18:01:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23152 for ; Wed, 16 Jan 2002 18:01:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24130 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 18:01:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22922; Wed, 16 Jan 2002 17:35:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA22891 for ; Wed, 16 Jan 2002 17:35:36 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22526 for ; Wed, 16 Jan 2002 17:35:32 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0GMXEkN021946; Wed, 16 Jan 2002 17:33:14 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Jan 2002 17:35:01 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E998@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Christer Holmberg'" , sip@ietf.org Subject: RE: [Sip] Question of looseroute draft Date: Wed, 16 Jan 2002 17:34:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, January 16, 2002 4:23 PM > To: sip@ietf.org > Subject: [Sip] Question of looseroute draft > > > > Hi, > > A cople of questions/clarifications on the looseroute draft. > > First, assume that a UAC inserts a preloaded route in the > initial INVITE > request, and the message is then received by a proxy. Now, > for whatever > policy/management/whatever reason the proxy is not allowed, > or does not > want to, forward the request to the next node in the node. > Should there > be a specific response code to indicate that to the client, or can an > existing code be used? Also, would it be useful to somehow in the > response include the Route header which caused the error response, so > that the client can (if possible) try another route (if available)? Adding such a thing would definitely be new behavior. The existing response codes should be sufficient. Consider the case where Route is not involved. A request goes out, traverses a few proxies getting its Request-URI rewritten, and runs into one of the conditions you mention above. What response, and how much information is returned then? Here's a specific example: A UA sends an invite to sip:help@bigplace.com. A proxy at bigplace.com forwards the request to sip:agent57@callcenter.net. But callcenter.net doesn't have an agent57, so it 404s. The original UA gets no information about agent57 being the failpoint. > > Second, just to clarify, my understanding of the draft is that it is > allowed for a proxy to insert a preloaded route in a request > it receives > from a client, as long as it doesn't remove/modify any possible Route > headers in the received message? The UAC may have no idea > which proxies, > ie which route, the request shall "visit", so... Yes - more specifically, a proxy can push values onto the front of the route stack. > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 18:13:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23311 for ; Wed, 16 Jan 2002 18:13:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24228 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 18:13:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23490; Wed, 16 Jan 2002 17:52:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23458 for ; Wed, 16 Jan 2002 17:52:44 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22867 for ; Wed, 16 Jan 2002 17:52:40 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0GMoMkN022050; Wed, 16 Jan 2002 17:50:22 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 17:52:09 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E999@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Christer Holmberg'" , Robert Sparks Cc: "'bernhard.honeisen@nokia.com'" , sip@ietf.org Subject: RE: [Sip] Loose Routing draft Date: Wed, 16 Jan 2002 17:52:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, January 16, 2002 4:15 PM > To: Robert Sparks > Cc: 'bernhard.honeisen@nokia.com'; sip@ietf.org > Subject: Re: [Sip] Loose Routing draft > > > > Hi, > > >>Is there a requirement, that loose routing is needed in > >>subsequent requests? > >There are people that want to be able to do this. > > I guess it shall be mentioned that it MUST be used for CANCEL (to the > INVITE request). We don't have anything new to deal with wrt CANCEL. The restrictions already in bis05 on how UACs form CANCELs and how proxies and UASs deal with them takes care of it. There will be no way for a proxy to choose to loose-route a CANCEL differently than it routed the associated request. > > Does anything need to be said about ACK, or can it be treated like any > "subsequent request"? I sketched through both 200-ACK and non-200-ACK, including non-200-ACK through stateless proxies, and found no special cases. If you've found one please let me know. > > Regards, > > Christer Holmberg > Ericsson Finland > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 18:14:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23345 for ; Wed, 16 Jan 2002 18:14:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA24271 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 18:14:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23368; Wed, 16 Jan 2002 17:50:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20084 for ; Tue, 8 Jan 2002 15:25:42 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09210 for ; Tue, 8 Jan 2002 15:25:41 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g08KDAvw012152; Tue, 8 Jan 2002 15:13:11 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 Jan 2002 15:14:54 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E928@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Robert Sparks , "'John.Hearty@Level3.com'" , taylor@nortelnetworks.com, wtm@research.att.com, sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) Date: Tue, 8 Jan 2002 15:14:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19881.224A3603" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19881.224A3603 Content-Type: text/plain; charset="iso-8859-1" I just realized I had fallen a little too deeply into the minimum value = only deployed value trap. Timer C needs to exist - a proxy element can't be expected to hold state forever, it has to have some point where it knows it can safely discard. If we don't discuss that in the specification, implementations will address it with local policy, potentially to the ruin of interoperation. Elements in real networks will tune this value (the spec should clearly point out that this MUST be configurable). So, a provider could set up a system that would let you work with AA for 45 minutes (or even all day) if they wanted to (at least the proxies wouldn't break the service). Market pressures will eventually drive them providers to use values that enable the applications that people are willing to pay for. So, I have to come back to the very starting point for this thread. Why do we need a minimum value? I think the 3 minutes we've negotiated so far has really been in the spirit of a recommended value, not a minimum. We only need to specify a minimum if use of the protocol with a smaller value will cause really bad things to happen to the network (this is the motivation for the minimum values for T1 yes?). This is different metric than having really bad things happen to applications running on the network. If the value is set to, say 32 seconds, bad things don't happen to the network. There may be some domains of control where its known that calls will complete fast or not at all, and its perfectly reasonable for intermediaries to discard state after 32s. If we make 3 minutes a minimum, we force them to keep state longer than they need it, or be noncompliant, neither of which makes much sense given that they are satisfying the needs of their application. So, I propose that we take what we've learned from the discussion so far and state the following: * Timer C must be configurable * A recommended value for Timer C is 3 minutes * A minimum value for Timer C is ? We haven't really been working to answer that last question - we've been focusing on when applications break, not when the protocol breaks the network. So, is a normative minimum really necessary? If somebody sets Timer C to zero, an INVITE transaction will never complete, which clearly breaks the protocol, so a minimum is needed. If the timer is around the transmission delay, the transaction can complete (though a race condition exists). So, some value larger than the transition delay is necessary. How much bigger? Probably not much. Jonathan's originally suggested 32 seconds. I think it could be much shorter - remember the metric - what breaks the network, not what breaks the applications. I propose the minimum be an RTT. RjS -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Tuesday, January 08, 2002 10:34 AM To: 'John.Hearty@Level3.com'; taylor@nortelnetworks.com; wtm@research.att.com; sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) 3 minutes seems a reasonable compromise. That will allow all but one of the ringtime applications I am aware of work. I will begrudgingly accept it. What this means is that any application that has a ringtime component can only count on the overall system providing a maximum of 3 minutes of ringtime (since some proxy in the path may have chosen to set Timer C to its 3 minute minimum). It also means that until we do some other kind of work, we preclude access to american airlines telephone service from the SIP world. (I _have_ stayed in the queue on their system for significantly longer than 5 minutes from multiple residential, wireless, and PBX phones, so something besides the timers discussed below is in play). So, since the consensus is that really long timer C's are not the way to address this problem, what's the alternative? Pretending the problem doesn't exist is unacceptable. RjS -----Original Message----- From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] Sent: Tuesday, January 08, 2002 9:38 AM To: taylor@nortelnetworks.com; wtm@research.att.com; sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) When I worked on the DMS several years ago, the timer was configurable, the company set it for 2 minutes. I'm hearing a general concensus the timer should be in the 1-5 minute range. Perhaps 3 minutes would be agreeable to most. Haven't heard anyone new pipe up for very long times... John Hearty Level3 -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Tuesday, January 08, 2002 8:10 AM To: 'William Marshall'; sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) A long time since I looked at that code, but I seem to recall a timeout after three minutes of ringing on the DMS. -----Original Message----- From: William Marshall [ mailto:wtm@research.att.com ] Sent: Monday, January 07, 2002 10:12 PM To: sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) In the circuit switch world, the equivalent of "Timer C" exists. On a 5ESS, ringback turns to fast busy after 3 minutes. On a 4ESS, it happens after 90 seconds. (Both figures were as of a few years ago, but I doubt they have changed). Perhaps someone from Nortel could speak of the DMS switches. Also as of a few years ago, business customers paid for ring time, so if still true, it is not clear why AA is "cheating". So a timeout value of a couple of minutes (like 4) would work just fine for calls into the PSTN, and would only get hit for a high-and-dry type of defect. Bill Marshall wtm@research.att.com -----original message----- From: John.Hearty@Level3.com Subject: RE: [Sip] Default value for Timer C (was #282) Date: Mon, 7 Jan 2002 15:56:14 -0700 I agree with Bob. AA is apparently cheating here, doing all their IVR functions without returning answer. I vote for the alternative, choosing a value on the order of minutes (not more than maybey three or four). John Hearty Level3 -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Monday, January 07, 2002 3:33 PM To: Bob Penfield Cc: Henry Sinnreich; 'Robert Sparks'; sip@ietf.org Subject: Re: [Sip] Default value for Timer C (was #282) This thread has stalled, and I think it requires some further input before we can resolve it. The issue was this: what minimum timer do we mandate for a proxy to hang onto invite transaction state after receiving 1xx? The issue is that some PSTN systems (american airlines in particular), appear to use early media while a user is on hold waiting, or using the DTMF based IVR system. The result is that a call from a PC to a PSTN number could, in theory go legitimately unanswered for hours, perhaps. This would require that Timer C in proxies be on the order of hours, which is quite large. An alternative is to not consider this case, and choose a smaller value, on the order of minutes. Both can result in DoS attacks, although in this case, the proxy shouldn't be storing transaction state for unauthenticated requests. Determining whether or not to go with a large value depends a lot on how common such systems are in the PSTN, and what the expectation is for them to be properly supported. Further inputs? -Jonathan R. Bob Penfield wrote: >>>I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>> > > The same problem occurs using old-world TDM equipment. If I use my > calling > card account to call AA, it hangs up after about a minute because the > calling card platform has a 60 second answer timer. AA is trying to save > money by having their ACD not return an answer and thus they don't have > to > pay for the 800 call. > > BTW, all billing is based on answer (2xx for SIP) being returned by the > called party. Some systems (usually in hotels) do use a timer when > answer > cannot be determined reliably (or they don't care). > > I'm curious as to whether this was isolated to a proxy or is it possible > the > TDM side of the gateway is dropping the call? If gateways have answer > timers > on this order of magnitude, having a really long timer in the proxy > won't > help. > > In any event, do we really need to support these cheaters in SIP and > open > ourselves to DOS attacks? > > >>I have exactly the same experience. >>As for: >> >> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, >>> >>I don't know how to tweak to and I don't ever want to know. >> >>Is there a better approach to fix the timer value or am I missing >>something? >> >>Thanks, Henry >> >> >>>-----Original Message----- >>>From: sip-admin@ietf.org [ mailto:sip-admin@ietf.org ] On Behalf Of >>> >>Robert >> >>>Sparks >>>Sent: Thursday, December 27, 2001 9:57 AM >>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks >>>Cc: sip@ietf.org >>>Subject: [Sip] Default value for Timer C (was #282) >>> >>>I'm talking about a _real problem_ that I have >>>_right now_ with the UAs on my desk and the gateways >>>I have access to. I have not _ever_ been able to successfully >>>use my SIP equipment to have a successful dialog with AA. >>>Try it - call +18004337300 - my environment drops the unanswered >>>call about 58 seconds into the first menu (yes, the first menu >>>is over a minute long). >>> >>>Now, if all the SIP parties involved allowed me to 1) control my >>>own Expires header, and 2) actually honored the thing, I could >>>work around it. But what about my tweak-phobic aquaintances >>>and relatives? >>> >>>In this case, the endpoints are dropping the call, but if I had >>>otherwise behaving endpoints, and a proxy in the middle with a >>>_default_ Timer C value that is too small, I am left with >>>at least one well-known service that just doesn't work. >>> >>>Now, we could get into a discussion about whether or not a service >>>_should_ run a whole bunch of time in an early media state, but >>>that's rather moot - we've worked really hard to make the system >>>allow it, and it will be used. We're here on purpose, not by >>>misfortune of oversight. >>> >>>As for your last paragraph - who says early media has to be free? >>> >>>RjS >>> >>> >>> >>>>From: Bob Penfield [ mailto:bpenfield@acmepacket.com ] >>>> >>>>>>If this is acceptable, it still leaves us with the question >>>>>>of what value we should recommend. I propose something >>>>>>long - order of .5 to 1 hour (remember that calls stay in a >>>>>>provisional state with early media when you are in the queue >>>>>>to talk to an AA representative). >>>>>> >>>>> >>>>>Egads, thats a long time! Your point on early media is well >>>>> > taken, > >>>>>though. Arguably, if this case happens, 1 hour is not even >>>>> >>>>enough, since >>>> >>>>>I have certainly been on hold for durations longer than >>>>> >>>>that. Probably 4 >>>> >>>>>hours is more reasonable. Once you've set the timer this >>>>> >>>>high, it may as >>>> >>>>>well be any finite number as far as the proxy is concerned. The >>>>> >>only >> >>>>>value in having a number at all (as opposed to infinity) is >>>>> >>>>very long >>>> >>>>>term garbage collection. You will get NO DoS attack prevention >>>>> >>from >> >>>>>numbers of this magnitude. You really need to be careful, >>>>> >>>>as a proxy, to >>>> >>>>>not create transaction state unless the request is >>>>> >>>>authenticated somehow. >>>> >>>>I don't think this really applies. I believe that most ACD >>>>systems that put >>>>you on hold actually do answer the call. Especially ones that >>>>have DTMF >>>>menus since some carriers block the caller to callee >>>>connection until it is >>>>answered. Many TDM switches that I have experience with will >>>>tear down an >>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3 >>>>minute timer >>>>would be adequate. >>>> >>>>But, this is not the TDM world. So, if we want to provide for >>>>unanswered >>>>calls being queued for long periods of time, maybe we could >>>>require the UAS >>>>to send periodic provisional responses and the proxy could >>>>reset Timer C. >>>>But that may be getting to complicated. >>>> >>>>Service providers who charge for these calls don't want their >>>>resources used >>>>for free for such a long period of time. >>>> >>>>cheers, >>>>(-:bob >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of >>>> > sip > >>>_______________________________________________ >>>Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >>> >> > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP 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_01C19881.224A3603 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] Default value for Timer C (was #282)
I just realized I had fallen a little too deeply into the minimum value = only deployed value
trap.
 
Timer C needs to exist - a proxy element can't be expected to hold state forever, it has
to have some point where it knows it can safely discard. If we don't discuss that in the
specification, implementations will address it with local policy, potentially to the ruin
of interoperation.
 
Elements in real networks will tune this value (the spec should clearly point out that this MUST
be configurable). So, a provider could set up a system that would let you work with AA
for 45 minutes (or even all day) if they wanted to (at least the proxies wouldn't break the service).
Market pressures will eventually drive them providers to use values that enable the applications
that people are willing to pay for.
 
So, I have to come back to the very starting point for this thread. Why do we need a minimum
value? I think the 3 minutes we've negotiated so far has really been in the spirit of a recommended
value, not a minimum.
 
We only need to specify a minimum if use of the protocol with a smaller value will cause really
bad things to happen to the network (this is the motivation for the minimum values for T1 yes?).
This is different metric than having really bad things happen to applications running on the
network.
 
If the value is set to, say 32 seconds, bad things don't happen to the network. There may be some
domains of control where its known that calls will complete fast or not at all, and its perfectly
reasonable for intermediaries to discard state after 32s. If we make 3 minutes a minimum, we force
them to keep state longer than they need it, or be noncompliant, neither of which makes much
sense given that they are satisfying the needs of their application.
 
So, I propose that we take what we've learned from the discussion so far and state the following:
* Timer C must be configurable
* A recommended value for Timer C is 3 minutes
* A minimum value for Timer C is ?
 
We haven't really been working to answer that last question - we've been focusing on when
applications break, not when the protocol breaks the network. So, is a normative minimum
really necessary? If somebody sets Timer C to zero, an INVITE transaction will never complete,
which clearly breaks the protocol, so a minimum is needed. If the timer is around the transmission
delay, the transaction can complete (though a race condition exists). So, some value larger than
the transition delay is necessary. How much bigger? Probably not much. Jonathan's originally
suggested 32 seconds. I think it could be much shorter - remember the metric - what breaks the
network, not what breaks the applications. I propose the minimum be an RTT.
 
RjS
 
 -----Original Message-----
From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
Sent: Tuesday, January 08, 2002 10:34 AM
To: 'John.Hearty@Level3.com'; taylor@nortelnetworks.com; wtm@research.att.com; sip@ietf.org
Subject: RE: [Sip] Default value for Timer C (was #282)

 ------_=_NextPart_001_01C19881.224A3603-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 16 19:51:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24840 for ; Wed, 16 Jan 2002 19:51:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA26751 for sip-archive@odin.ietf.org; Wed, 16 Jan 2002 19:51:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25706; Wed, 16 Jan 2002 19:06:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25682 for ; Wed, 16 Jan 2002 19:06:17 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24093 for ; Wed, 16 Jan 2002 19:06:15 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0H03fkN022559; Wed, 16 Jan 2002 19:03:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 19:05:29 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E99B@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Robert Sparks , "'John.Hearty@Level3.com'" , taylor@nortelnetworks.com, wtm@research.att.com, sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) Date: Wed, 16 Jan 2002 19:05:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org And, of course, this was the post that got caught in the moderator queue finally popping out. Disregard it please. RjS -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Tuesday, January 08, 2002 2:15 PM To: Robert Sparks; 'John.Hearty@Level3.com'; taylor@nortelnetworks.com; wtm@research.att.com; sip@ietf.org Subject: RE: [Sip] Default value for Timer C (was #282) I just realized I had fallen a little too deeply into the minimum value = only deployed value trap. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 03:22:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10038 for ; Thu, 17 Jan 2002 03:22:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA20466 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 03:22:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17736; Thu, 17 Jan 2002 02:03:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA17707 for ; Thu, 17 Jan 2002 02:03:49 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06072 for ; Thu, 17 Jan 2002 02:03:47 -0500 (EST) Received: from madrid.ericsson.se (madrid.es.eu.ericsson.se [159.107.53.220]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0H73kJ03310; Thu, 17 Jan 2002 08:03:46 +0100 (MET) Received: from lmf.ericsson.se by madrid.ericsson.se (SMI-8.6/SMI-SVR4) id IAA16794; Thu, 17 Jan 2002 08:03:39 +0100 Message-ID: <3C467744.8C1BC6EC@lmf.ericsson.se> Date: Thu, 17 Jan 2002 09:03:32 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: sip@ietf.org Subject: Re: [Sip] Question of looseroute draft References: <9BF66EBF6BEFD942915B4D4D45C051F338E998@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Hi, >> >>A cople of questions/clarifications on the looseroute draft. >> >>First, assume that a UAC inserts a preloaded route in the >>initial INVITE request, and the message is then received by a proxy. Now, >>for whatever policy/management/whatever reason the proxy is not allowed, >>or does not want to, forward the request to the next node in the node. >>Should there be a specific response code to indicate that to the client, or can an >>existing code be used? Also, would it be useful to somehow in the >>response include the Route header which caused the error response, so >>that the client can (if possible) try another route (if available)? >Adding such a thing would definitely be new behavior. >The existing response codes should be sufficient. Consider >the case where Route is not involved. A request goes out, >traverses a few proxies getting its Request-URI rewritten, >and runs into one of the conditions you mention above. What >response, and how much information is returned then? Here's >a specific example: > >A UA sends an invite to sip:help@bigplace.com. A proxy at >bigplace.com forwards the request to sip:agent57@callcenter.net. >But callcenter.net doesn't have an agent57, so it 404s. >The original UA gets no information about agent57 being the failpoint. True, but that is a little different case, because now the message has at least been sent to callcenter.net, which then doesn't find the user. My case was when a proxy process the route, and the finds out that the next hop is a "forbidden" hop (ie the proxy is not allowed to - for whatever reason - send the message to callcenter.com in the first place), so it won't even try to send the message there. I don't think 404 is the right code in that case. Maybe 485? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 07:07:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12833 for ; Thu, 17 Jan 2002 07:07:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA28881 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 07:07:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27655; Thu, 17 Jan 2002 06:39:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27625 for ; Thu, 17 Jan 2002 06:39:11 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12028 for ; Thu, 17 Jan 2002 06:39:08 -0500 (EST) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id g0HCgQM02026; Thu, 17 Jan 2002 06:42:27 -0600 Message-ID: <01b801c19f4b$690651f0$2164a8c0@flak> From: "Dean Willis" To: "Honeisen Bernhard \(NET/Helsinki\)" , Cc: "'ext Robert Sparks'" References: Subject: Re: [Sip] Attention - comment on Loose Routing draft Date: Thu, 17 Jan 2002 04:55:26 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hmm, RjS may disagree, but I think that the retargeting of the message at X might override the service routing in the original request. Changing the request URI means to me "don't send it to where it was being sent, send it to this other place instead". Given this logic, service route points downstream from X probably don't matter anymore. -- Dean ----- Original Message ----- From: "Honeisen Bernhard (NET/Helsinki)" To: Cc: "'ext Robert Sparks'" Sent: Tuesday, January 15, 2002 9:05 AM Subject: RE: [Sip] Attention - comment on Loose Routing draft > Hi RjS! > > Some question: > > Consider a situation, where a request is directed > to (B) and two service elements (X) and (Y) have > to be visited before. > (X) performs a service, which replaces the intended > destination URL, i.e. (B), whereas (Y) executes > some feature, which depends on the output of (X). > > When the request arrives at (X), the R-URI / Route > could look like: > - R-URI: > - Route: , > (The intended destination has been appended earlier > to Route as per section 5.2 in your I/D) > > How can (X) now apply the destination URL relacing feature? > My first guess was, that (X) would modify the last entry > in the Route, i.e. (B). > > Your first proposal in section 2 prohibits such behavior: > "[...] an element [...] MUST NOT modify or remove > subsequent Route header field values." > > Is this restriction intended also for such cases or could > we relax it to allow modifying of the last entry in Route? > Would marking the last Route entry as the intended > destination (and allow modifying of such only) solve > this issue? > > Greetings, > Bernie > > > PS: Some Typos: > > - section 5.5, F7-F12: > s/Contact: sip:jbj@212.28.214.227/Contact: sip:jbj@212.28.214.228/ > > - section 5.5. F3/F4: > - Shouldn't maddr in F4 contain a different IP-address > than in F3? > - Maybe add a FQDN <-> IP mapping table to ease > the understanding of the examples. > > - section 5.8: > s/senting/sending/ > > > > >-----Original Message----- > >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > >Sent: 14. January 2002 20:58 > >To: 'sip@ietf.org' > >Subject: [Sip] Attention - comment on Loose Routing draft > > > > > >The draft below contains the resolution to a large > >set of open issues around processing of the Route header, > >preloaded routes, and the use of default outbound proxies. > >The plan is to modify bis to reflect these proposals. > > > >Please review it as soon as you can and comment if you > >see real problems. Silence will be taken as consent. > > > >RjS > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > >> Sent: Thursday, January 10, 2002 10:46 PM > >> To: 'sip@ietf.org' > >> Subject: [Sip] Loose Routing draft > >> > >> > >> I just submitted a draft refining the post I sent > >> out after IETF52 on the loose routing proposal. > >> > >> Until it appears in the archive, you can find it at > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt > >> or > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html > >> > >> > >> RjS > >> > >> _______________________________________________ > >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 07:13:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12938 for ; Thu, 17 Jan 2002 07:13:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA28955 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 07:13:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28036; Thu, 17 Jan 2002 06:49:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA28004 for ; Thu, 17 Jan 2002 06:49:04 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12414; Thu, 17 Jan 2002 06:49:02 -0500 (EST) Message-Id: <200201171149.GAA12414@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 17 Jan 2002 06:49:02 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-replaces-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The SIP Replaces Header Author(s) : B. Biggs, R. Dean, R. Mahy Filename : draft-ietf-sip-replaces-00.txt Pages : 16 Date : 16-Jan-02 This document proposes a new header for use with the SIP call control architecture. The Replaces header is used in peer-to-peer call control to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: 'Attended Transfer' and 'Retrieve from Call Park'. Note that definition of these example features is non- normative. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-replaces-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-replaces-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020116142855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-replaces-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-replaces-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020116142855.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 17 10:49:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19487 for ; Thu, 17 Jan 2002 10:49:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07279 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 10:49:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05989; Thu, 17 Jan 2002 10:22:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05956 for ; Thu, 17 Jan 2002 10:22:51 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18556 for ; Thu, 17 Jan 2002 10:22:48 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id PAA16087; Thu, 17 Jan 2002 15:19:10 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id PAA14990; Thu, 17 Jan 2002 15:22:42 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Jan 2002 08:22:42 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B3715E@n0214idc1.oss.level3.com> To: dean.willis@softarmor.com Cc: rsparks@dynamicsoft.com, bernhard.honeisen@nokia.com, sip@ietf.org Subject: RE: [Sip] Attention - comment on Loose Routing draft Date: Thu, 17 Jan 2002 08:22:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I would have to disagree with you too. This sounds like trouble brewing, especially in transactions subsequent to the first. Take for example a firewall control proxy downstream from X. An initial Invite sets up firewall resources. If a re-Invite comes through and X decides service route points downstream from X don't matter anymore, you just stranded firewall resources. John Hearty Level3 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, January 17, 2002 3:55 AM To: Honeisen Bernhard (NET/Helsinki); sip@ietf.org Cc: 'ext Robert Sparks' Subject: Re: [Sip] Attention - comment on Loose Routing draft Hmm, RjS may disagree, but I think that the retargeting of the message at X might override the service routing in the original request. Changing the request URI means to me "don't send it to where it was being sent, send it to this other place instead". Given this logic, service route points downstream from X probably don't matter anymore. -- Dean ----- Original Message ----- From: "Honeisen Bernhard (NET/Helsinki)" To: Cc: "'ext Robert Sparks'" Sent: Tuesday, January 15, 2002 9:05 AM Subject: RE: [Sip] Attention - comment on Loose Routing draft > Hi RjS! > > Some question: > > Consider a situation, where a request is directed > to (B) and two service elements (X) and (Y) have > to be visited before. > (X) performs a service, which replaces the intended > destination URL, i.e. (B), whereas (Y) executes > some feature, which depends on the output of (X). > > When the request arrives at (X), the R-URI / Route > could look like: > - R-URI: > - Route: , > (The intended destination has been appended earlier > to Route as per section 5.2 in your I/D) > > How can (X) now apply the destination URL relacing feature? > My first guess was, that (X) would modify the last entry > in the Route, i.e. (B). > > Your first proposal in section 2 prohibits such behavior: > "[...] an element [...] MUST NOT modify or remove > subsequent Route header field values." > > Is this restriction intended also for such cases or could > we relax it to allow modifying of the last entry in Route? > Would marking the last Route entry as the intended > destination (and allow modifying of such only) solve > this issue? > > Greetings, > Bernie > > > PS: Some Typos: > > - section 5.5, F7-F12: > s/Contact: sip:jbj@212.28.214.227/Contact: sip:jbj@212.28.214.228/ > > - section 5.5. F3/F4: > - Shouldn't maddr in F4 contain a different IP-address > than in F3? > - Maybe add a FQDN <-> IP mapping table to ease > the understanding of the examples. > > - section 5.8: > s/senting/sending/ > > > > >-----Original Message----- > >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > >Sent: 14. January 2002 20:58 > >To: 'sip@ietf.org' > >Subject: [Sip] Attention - comment on Loose Routing draft > > > > > >The draft below contains the resolution to a large > >set of open issues around processing of the Route header, > >preloaded routes, and the use of default outbound proxies. > >The plan is to modify bis to reflect these proposals. > > > >Please review it as soon as you can and comment if you > >see real problems. Silence will be taken as consent. > > > >RjS > > > >> -----Original Message----- > >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > >> Sent: Thursday, January 10, 2002 10:46 PM > >> To: 'sip@ietf.org' > >> Subject: [Sip] Loose Routing draft > >> > >> > >> I just submitted a draft refining the post I sent > >> out after IETF52 on the loose routing proposal. > >> > >> Until it appears in the archive, you can find it at > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt > >> or > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html > >> > >> > >> RjS > >> > >> _______________________________________________ > >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 17 10:51:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19567 for ; Thu, 17 Jan 2002 10:51:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07326 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 10:51:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06266; Thu, 17 Jan 2002 10:29:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06237 for ; Thu, 17 Jan 2002 10:29:14 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18768 for ; Thu, 17 Jan 2002 10:29:11 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0HFQrkN025970; Thu, 17 Jan 2002 10:26:54 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Jan 2002 10:28:41 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E99F@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Christer Holmberg'" Cc: sip@ietf.org Subject: RE: [Sip] Question of looseroute draft Date: Thu, 17 Jan 2002 10:28:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > >A UA sends an invite to sip:help@bigplace.com. A proxy at > >bigplace.com forwards the request to sip:agent57@callcenter.net. > >But callcenter.net doesn't have an agent57, so it 404s. > >The original UA gets no information about agent57 being the > failpoint. > > True, but that is a little different case, because now the message has > at least been sent to callcenter.net, which then doesn't find > the user. > > My case was when a proxy process the route, and the finds out that the > next hop is a "forbidden" hop (ie the proxy is not allowed to - for > whatever reason - send the message to callcenter.com in the first > place), so it won't even try to send the message there. I don't think > 404 is the right code in that case. Maybe 485? Ok, to getting a little closer to your case, bigplace discovers that callcenter.net has no DNS records at the moment or is configured to not leave the company over anything but TLS (which callcenter.net doesn't support) or learns that it is about to be taken out of service. There are appropriate response codes for those, and they aren't all the same. My point is that whatever would have been appropriate in the absence of Route will still be appropriate in the presence of Route. > > Regards, > > Christer Holmberg > Ericsson Finland > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 15:04:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06399 for ; Thu, 17 Jan 2002 15:04:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21722 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 15:04:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20579; Thu, 17 Jan 2002 14:39:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20548 for ; Thu, 17 Jan 2002 14:39:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03122 for ; Thu, 17 Jan 2002 14:39:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0HJdDGe021882; Thu, 17 Jan 2002 14:39:14 -0500 (EST) Message-ID: <3C47283E.9040407@dynamicsoft.com> Date: Thu, 17 Jan 2002 14:38:38 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org, Jonathan Rosenberg Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] solving early media, HERFP, and unifying manyfolks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I've been working on some of the open issues in bis, mainly HERFP, the usage of a three-way SDP exchange, overlapping INVITE, and unification of O/A with manyfolks. In the process, I came up with a joint solution to all of these problems. I have written it up, along with call flows showing how it is used in all cases, in an I-D that I have just submitted. Until that I-D appears, you may pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt In summary, the draft proposes that COMET take on a new, much broader definition, encompassing the semantics of UPDATE, and then some, as has been discussed on the list. The draft postulates how manyfolks can be recast to fit within the offer/answer model, and then shows how COMET can also be used to update not just session parameters, but other state, in an effort to resolve HERFP. For those confused about what HERFP is, it is a rather nasty forking problem that interferes with services, it is discussed in detail in the above draft. The proposal would change bis in a simple way, which is to generalize the conditions under which SDP could appear in SIP. THis generalization would imply the current behavior (INV/200 or 200/ACK) for baseline implementations, but would support richer exchanges for those supporting the new COMET. Furthermore, the draft proposes that manyfolks be sufficiently generalized to provide this new form of COMET. I would also like to point out that dynamicsoft may have IPR against this draft. I will say, honestly, that we have been forced into the corner of making IPR claims against IETF documents due to the existence of claims against IETF documents that have been made by others. However, our aim is ONLY defensive. As such, I have worked with our attorneys to work out licensing terms which I think everyone will find most agreeable, and indeed, laudable. They are: dynamicsoft may seek patent protection on technology described in documents which dynamicsoft submits for use in IETF standards discussions. In relation to any IETF standard incorporating any such technology, dynamicsoft will grant a royalty free non-exclusive license to Qualified Parties to utilize such technology if necessary for practice of IETF standards implemented as a result of dynamicsoft's submission. As used herein, Qualified Parties means a party who has not, does not and will not assert, in litigation or otherwise, including in licensing discussions, any patent or other intellectual property right against dynamicsoft. Any such license to a Qualified Party shall terminate at once if such party asserts a patent or other intellectual property right against dynamicsoft. dynamicsoft will grant non-exclusive licenses to Non-Qualified Parties on reasonable, reciprocal non-discriminatory terms and conditions. These terms will also appear shortly on the IPR claims page at the IETF site. A summary of these terms is basically "leave us alone, and this is free". We feel that this is very much in the spirit of the IETF practices and attitudes towards IPR, but recognizes that companies have a need to protect themselves. I would encourage others who have IPR to make their IPR available under similar terms, so we can focus on technology work rather than acting as amateur lawyers. Comments and questions welcome, as always. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 16:03:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12772 for ; Thu, 17 Jan 2002 16:03:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24344 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 16:03:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23210; Thu, 17 Jan 2002 15:35:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23180 for ; Thu, 17 Jan 2002 15:35:37 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11936 for ; Thu, 17 Jan 2002 15:35:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0HKZYGe022014; Thu, 17 Jan 2002 15:35:36 -0500 (EST) Message-ID: <3C473574.4080109@dynamicsoft.com> Date: Thu, 17 Jan 2002 15:35:00 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: Robert Sparks , sip@ietf.org Subject: Re: [Sip] Question of looseroute draft References: <3C467744.8C1BC6EC@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, >>Adding such a thing would definitely be new behavior. >>The existing response codes should be sufficient. Consider >>the case where Route is not involved. A request goes out, >>traverses a few proxies getting its Request-URI rewritten, >>and runs into one of the conditions you mention above. What >>response, and how much information is returned then? Here's >>a specific example: >> >>A UA sends an invite to sip:help@bigplace.com. A proxy at >>bigplace.com forwards the request to sip:agent57@callcenter.net. >>But callcenter.net doesn't have an agent57, so it 404s. >>The original UA gets no information about agent57 being the failpoint. >> > > True, but that is a little different case, because now the message has > at least been sent to callcenter.net, which then doesn't find the user. > My case was when a proxy process the route, and the finds out that the > next hop is a "forbidden" hop (ie the proxy is not allowed to - for > whatever reason - send the message to callcenter.com in the first > place), so it won't even try to send the message there. I don't think > 404 is the right code in that case. Maybe 485? Let me make sure I understand. You want to know what a proxy should do if the next Route header is one it is not willing to honor? For example, if bigplace.com is administratively forbidden from sending to callcenter.com, but callcenter.com was in a Route header received in a request sent to bigplace.com? In other words, you are worrying about the case where a user has constructed a loose route through elements which, as a result of administrative policy, cannot be visited in that order. The answer is clear; it can loose route the request to whatever elements it is allowed to send to. If, for some reason, it cannot loose route it somewhere, but cannot honor the route, well, I think 403 is fine. I will furhter add that this case just shouldn't happen. One cannot arbitrarily insert loose routes. A route set needs to be TOLD to you, either through headers (like Record-ROute, Path) or through administrative configuration when you know what those headers should be. Any other case won't work for many reasons. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 16:08:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12901 for ; Thu, 17 Jan 2002 16:08:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24486 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 16:08:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23331; Thu, 17 Jan 2002 15:40:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23300 for ; Thu, 17 Jan 2002 15:40:39 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12087 for ; Thu, 17 Jan 2002 15:40:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0HKcfGe022027; Thu, 17 Jan 2002 15:38:42 -0500 (EST) Message-ID: <3C47362F.7060504@dynamicsoft.com> Date: Thu, 17 Jan 2002 15:38:07 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Charles Eckel CC: Shail Bhatnagar , Brian Stucker , Scott Orton , "'Kiranmai Pavoori'" , vkg , sip Subject: Re: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! References: <3C3E06B3.F37D979F@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Charles Eckel wrote: > Maybe its a small point, but if fallback values are going to be > specified, it may be of value to state a context sensitive fallback > value. For a contact, I agree that 3600 is reasonable; however, for an > INVITE a value of 180 seems more appropriate. I thought these were the > default to assume in case of the absence of any Expires header for the > respective cases, but I don't see any mention of such defaults in > bis-05. Just my 2 cents. There is no need for defaults for INVITE, since the UAC will CANCEL in any case. The only place where we want this default defined is registrations. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 16:13:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13007 for ; Thu, 17 Jan 2002 16:13:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24596 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 16:13:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23415; Thu, 17 Jan 2002 15:42:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23384 for ; Thu, 17 Jan 2002 15:42:13 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12164 for ; Thu, 17 Jan 2002 15:42:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0HKgFGe022036; Thu, 17 Jan 2002 15:42:16 -0500 (EST) Message-ID: <3C473703.6000008@dynamicsoft.com> Date: Thu, 17 Jan 2002 15:41:39 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Open Issue #351: non-SIP URL as AOR References: <3C32A24A.7080904@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There were no comments on this issue, so the proposed resolution stands. -Jonathan R. Jonathan Rosenberg wrote: > Issue: > > Do we allow for non-SIP URLs as the address-of-record in a REGISTER? > That is, can a REGISTER have a non-SIP URL in the To field? The spec is > silent on this, although I think it generally assumes that its OK. > > I would argue that SIP can only really define proper address bindings > for URLs in its own space (i.e., SIP URLs). For example, I do not think > it is appropriate for a phone to register that tel:+19739525000 belongs > to it. The ownership of this e.164 number is administered outside the > scope of SIP systems, and is more the domain of enum to worry about. A > proxy would not have access to the proper authorization for such a > binding; in enum, these will likely be done statically based on all > sorts of complex multi-tiered administration. > > So, my proposal is that REGISTER be restricted to SIP URls in the To > field (Contact can, of course, be anything). > > -Jonathan R. > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 16:18:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13102 for ; Thu, 17 Jan 2002 16:18:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24677 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 16:18:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23628; Thu, 17 Jan 2002 15:50:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23596 for ; Thu, 17 Jan 2002 15:50:15 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12307 for ; Thu, 17 Jan 2002 15:50:07 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0HKo2Ge022045; Thu, 17 Jan 2002 15:50:03 -0500 (EST) Message-ID: <3C4738D5.7080208@dynamicsoft.com> Date: Thu, 17 Jan 2002 15:49:25 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: pnath@hss.hns.com CC: sip@ietf.org Subject: Re: [Sip] bis-06 release date? References: <65256B43.001CA859.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit pnath@hss.hns.com wrote: > > > Hi , > > > >>There has been little comment on the proposal to deprecate loop >>detection; one email in favor, and a few questions. Without any >>additional comment it will be removed from bis-06. >> > > > > Just curious... When is the rfc2543 bis06 expected to be out ? We are working diligently on it. It should be a matter of days. > Will it be after closure of all remaining open issues? That is the hope. We want to last call -06. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 16:29:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13472 for ; Thu, 17 Jan 2002 16:29:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25064 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 16:29:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24314; Thu, 17 Jan 2002 16:02:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24283 for ; Thu, 17 Jan 2002 16:02:52 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12760 for ; Thu, 17 Jan 2002 16:02:47 -0500 (EST) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g0HL2ms58877; Thu, 17 Jan 2002 16:02:48 -0500 (EST) Reply-To: From: "Brett Tate" To: "'sip'" Subject: RE: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! Date: Thu, 17 Jan 2002 16:05:13 -0500 Message-ID: <000101c19f9a$a8328e30$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3C47362F.7060504@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > There is no need for defaults for INVITE, > since the UAC will CANCEL in any case. > The only place where we want this default > defined is registrations. Not true. If the UAS does not apply some local or received expiration value, the phone would ring indefinitely when the CANCEL is not received because of UAC or network outage. If UAC supports INFO or 100rel, they could be used by UAS to ensure the UAC still considers the dialogue active. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 16:34:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13665 for ; Thu, 17 Jan 2002 16:34:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25735 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 16:34:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24423; Thu, 17 Jan 2002 16:05:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24391 for ; Thu, 17 Jan 2002 16:05:39 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12864 for ; Thu, 17 Jan 2002 16:05:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0HL51Ge022052; Thu, 17 Jan 2002 16:05:02 -0500 (EST) Message-ID: <3C473C59.6010405@dynamicsoft.com> Date: Thu, 17 Jan 2002 16:04:25 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Dorgham Sisalem , sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <3C388ED4.19AB555D@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've been working through the various possibilities with Henning. Our conclusion is that any of these redirect-to-tcp mecahnisms are frought with problems. Therefore, the proposal is the following: 1. if the request is larger than some threshold (1000 or somehting), you MUST use TCP (after compression, of course). If the path MTU is known, you need to use TCP if the request is greater than that value - 300 or so. 2. It is RECOMMENDED to use TCP to communicate with a server when you know a NAT is in the way. Point (1) is based on the observation that in most cases, the response is not substanially larger than the request. This is certainly true for MESSAGE, BYE. It is not true for OPTIONS, admittedly, but those are not record-routed and the requests are also ususally small. The main item will be record-routes, which can be many hundreds of bytes. Therefore, we leave a bit of buffer space in the threshold to account for that. Thus, we should be OK. The second point ensures that, if fragmentation of the response does happen, there hopefully isn't a nat in the way, since that is the really bad case. A refinement on this is what will go into bis-06 unless someone has a really big beef with it. -Jonathan R. Henning G. Schulzrinne wrote: > Dorgham Sisalem wrote: > >>Hello, >> looking at all the complexity of 499 and UDP to TCP transition I am >> wondering if fragmentation is really worth the trouble. For the case >> of signaling I hardly imagine the messages will get big enough so as >> to worry about congestion due to retransmission (just because a SIP >> > > I think the congestion aspect deserves an additional sentence or two. > Effectively, SIP behaves like TCP with a window size of 1 segment and > only time-out based retransmission, i.e., the most conservative > operational mode of TCP. Depending on the RTT estimate, the SIP timers > will obviously differ, but their growth behavior is also similar. > > The main problem is that with fragmentation, SIP may fail completely if > various NATs and firewalls get in the way. That, in my view, is the > bigger issue. > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 18:09:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15176 for ; Thu, 17 Jan 2002 18:09:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA28899 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 18:09:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28098; Thu, 17 Jan 2002 17:36:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28069 for ; Thu, 17 Jan 2002 17:36:35 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14712 for ; Thu, 17 Jan 2002 17:36:32 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0HMa6Ge022151; Thu, 17 Jan 2002 17:36:07 -0500 (EST) Message-ID: <3C4751B1.8040208@dynamicsoft.com> Date: Thu, 17 Jan 2002 17:35:29 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Henning G. Schulzrinne" , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C34C2AD.3000301@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Here is the concrete proposal on this issue: 1. how a UA renders user input to a URL is local policy, of course 2. in the absence of any specific policy or indications on how to interpret an address, it is RECOMMENDED that it be used to generate a SIP URL, with that value in the user part, and the domain equal to that of the provider for the UA. This allows the information to be interpreted by the user's provider. I think a statement along the lines of 2 is still needed, since otherwise, we will have to mandate tel URLs everywhere, or otherwise add additional configuration about the policy of the domain. We need more configuration like we need a hole in the head. I think the above proposal provides sufficient flexibility while still allowing for configuration-less flexibility. Unless I hear something on this by next Tuesday, this resolution is in bis-06. -Jonathan R. Jonathan Rosenberg wrote: > > Henning G. Schulzrinne wrote: > > >>Jonathan Rosenberg wrote: >> >> > >>>Do you remember what the specific problem is? >>> >>> >>http://cider.caida.org/~evi/sigcomm/paper.html >> >>"This last example is typical of a bug in the DNS data files at the >>local site. If a name that should end in a dot and therefore be >> > absolute > >>has no dot, the local nameserver will add the local domain to complete >>the name. A bug in at least one nameserver implementation >>adds the local domain recursively until it is 256 characters long (the >>limit). The WSCOOPER example has been truncated to fit the >>page!" >> >>I'm not arguing that this is a big deal, particularly since for SIP >>URLs, it's easier to tell if you need to add the domain or not. >> > > > Yeah, this one seems like a non-issue. > > > >>Did >> >>>the proxy do the wrong thing by interpreting the tel URL as a PSTN >>>number? Looking at either element individually, it doesn't seem like >>>either did the wrong thing, which would lead me to believe that the >>>spec has to say something here so it doesn't happen. >>> >>> >>I just don't see how we can mandate the translation of user input into >>protocol elements. If anything, this belongs in more informal >> > documents > >>such as "Suggestions for IP phones" that Henry Sinnreich and others >> > are > >>putting together. >> > > > > Its hard to argue with this point. I'll back off some. I still think > something is needed in the base spec; possibly a statement that all > proxies need to support the tel URL, along with a reasonable definition > of what the semantics of a particular tel URL are when used with SIP. > > So long as we have a clear definition of what sip:123 v. tel:123 v. > tel:+123 means, > > then the UI can do whatever it wants to construct a URL. > > -Jonathan R. > > > > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 18:18:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15305 for ; Thu, 17 Jan 2002 18:18:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29084 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 18:18:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28323; Thu, 17 Jan 2002 17:49:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28292 for ; Thu, 17 Jan 2002 17:49:51 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14870 for ; Thu, 17 Jan 2002 17:49:48 -0500 (EST) Received: from madrid.ericsson.se (madrid.es.eu.ericsson.se [159.107.53.220]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0HMnnJ19232; Thu, 17 Jan 2002 23:49:49 +0100 (MET) Received: from lmf.ericsson.se by madrid.ericsson.se (SMI-8.6/SMI-SVR4) id XAA07317; Thu, 17 Jan 2002 23:49:36 +0100 Message-ID: <3C475514.D8F65901@lmf.ericsson.se> Date: Fri, 18 Jan 2002 00:49:56 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Robert Sparks , sip@ietf.org Subject: Re: [Sip] Question of looseroute draft References: <3C467744.8C1BC6EC@lmf.ericsson.se> <3C473574.4080109@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>>Adding such a thing would definitely be new behavior. >>>The existing response codes should be sufficient. Consider >>>the case where Route is not involved. A request goes out, >>>traverses a few proxies getting its Request-URI rewritten, >>>and runs into one of the conditions you mention above. What >>>response, and how much information is returned then? Here's >>>a specific example: >>> >>>A UA sends an invite to sip:help@bigplace.com. A proxy at >>>bigplace.com forwards the request to sip:agent57@callcenter.net. >>>But callcenter.net doesn't have an agent57, so it 404s. >>>The original UA gets no information about agent57 being the failpoint. >>> >> >>True, but that is a little different case, because now the message has >>at least been sent to callcenter.net, which then doesn't find the user. >>My case was when a proxy process the route, and the finds out that the >>next hop is a "forbidden" hop (ie the proxy is not allowed to - for >>whatever reason - send the message to callcenter.com in the first >>place), so it won't even try to send the message there. I don't think >>404 is the right code in that case. Maybe 485? > >Let me make sure I understand. You want to know what a proxy should do >if the next Route header is one it is not willing to honor? For example, >if bigplace.com is administratively forbidden from sending to >callcenter.com, but callcenter.com was in a Route header received in a >request sent to bigplace.com? > >In other words, you are worrying about the case where a user has >constructed a loose route through elements which, as a result of >administrative policy, cannot be visited in that order. Yes. >The answer is clear; it can loose route the request to whatever elements >it is allowed to send to. If, for some reason, it cannot loose route it >somewhere, but cannot honor the route, well, I think 403 is fine. > >I will furhter add that this case just shouldn't happen. One cannot >arbitrarily insert loose routes. A route set needs to be TOLD to you, >either through headers (like Record-ROute, Path) or through >administrative configuration when you know what those headers should be. >Any other case won't work for many reasons. Yes, but that administrative configuration may not be up to date with things like temporary network failures etc, proxies temporary taken out of service, temporary new routes because of those issues, etc etc etc. In a mobile world the server may also be "out of reach" for certain periods... Also, if Record-Route was used to tell me the route, I may have received it who-knows-when, and it may not more valid anymore... That actually brings another question: should be allow expires parameters in R-R too (like in Contact)? I think 403 is fine, and I guess the Retry-After header could be included to tell when the client may try again - IF the route is valid as such. The question is that if it should be mentioned in the draft? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 19:07:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16000 for ; Thu, 17 Jan 2002 19:07:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA00818 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 19:07:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00169; Thu, 17 Jan 2002 18:47:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00137 for ; Thu, 17 Jan 2002 18:47:38 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15740 for ; Thu, 17 Jan 2002 18:47:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0HNlIGe022228; Thu, 17 Jan 2002 18:47:20 -0500 (EST) Message-ID: <3C476262.5070500@dynamicsoft.com> Date: Thu, 17 Jan 2002 18:46:42 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] DEPRECATION WARNING: BYE without tags!!!!!! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, Bis-05 already mandates that a BYE come with tags in it. This means that a BYE sent instead of a CANCEL, before a dialog is created (early or otherwise) will not be processed. So, if you have a UAC that sends BYE instead of CANCEL before the 1xx, you will no longer be able to hang up a call in this acse to a bis compliant device. This is open issue #325. I sent a note to the list on Jan 2 explaining this case, and got no replies. I am hoping to subject header will alert anyone that needs to speak up about this. I would be happy if we can keep the text in bis-05, but people need to be aware of this limitation. THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 19:19:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16157 for ; Thu, 17 Jan 2002 19:19:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01140 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 19:19:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29881; Thu, 17 Jan 2002 18:42:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29852 for ; Thu, 17 Jan 2002 18:42:01 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15645 for ; Thu, 17 Jan 2002 18:41:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0HNfnGe022219; Thu, 17 Jan 2002 18:41:53 -0500 (EST) Message-ID: <3C476119.9020604@dynamicsoft.com> Date: Thu, 17 Jan 2002 18:41:13 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: brett@broadsoft.com CC: "'sip'" Subject: Re: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! References: <000101c19f9a$a8328e30$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Brett Tate wrote: >>There is no need for defaults for INVITE, >>since the UAC will CANCEL in any case. >>The only place where we want this default >>defined is registrations. >> > > Not true. If the UAS does not apply some > local or received expiration value, the > phone would ring indefinitely when the > CANCEL is not received because of UAC or > network outage. If UAC supports INFO or > 100rel, they could be used by UAS to > ensure the UAC still considers the dialogue > active. it doesn't seem that important to support a case which requires: (1) the uas to not be bis-compliant, (2) expires is needed in INVITE (3) uas doesn't apply local policy to stop ringing after some time (very unlikely, I think) (4) there is a network outage. The odds of simultaneous occurence of all of these four seem very low to me. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 19:47:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16452 for ; Thu, 17 Jan 2002 19:47:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01939 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 19:47:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01111; Thu, 17 Jan 2002 19:18:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00999 for ; Thu, 17 Jan 2002 19:18:41 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16147 for ; Thu, 17 Jan 2002 19:18:39 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0I0IaGe022407; Thu, 17 Jan 2002 19:18:37 -0500 (EST) Message-ID: <3C4769B9.6020501@dynamicsoft.com> Date: Thu, 17 Jan 2002 19:18:01 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] Open Issue #290: Registrar increasing registration life time References: <000901c19e45$a4456d70$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I would really like to resolve this one finally. From what I can tell, people seem to agree that, generally speaking, the registrar shouldn't increase it, and if the interval is too low, it can reject it. Brett's concern is backwards compatibility. However, I think I have an easier answer for that. I suspect there are zero existing UA's that ever include an expires less than one hour. So, as long as we mandate that a proxy support registrations of at least one hour (i.e., it not reject registrations greater than one hour because they are too short), we'll be backwards compatible in practice. So, to summarize: 1. registrars can't increase the interval 2. registrars must not reject registrartions less than one hour 3. registrars may reject registrations less that one hour, with some TBD response code May I please hear a yea/nea from the people in this thread?? -Jonathan R. Brett Tate wrote: >>Eventually, someone will find something >>where changing 1 minute to 1 hour would >>be just as damaging. >> > > That is a two way street. A registrar with > 100,000 subscribers might not desire to > accommodate its users extending contact > expirations through registrations every 30 > seconds. However I guess this gets into > an issue of billing for capacity-usage. > > >>>A reasonable argument. The point of extending the >>>URI lifetime was not to do this kind of thing. It >>>is meant as a defensive mechanism for the server >>>to say basically that it's timer resolution is greater >>>than what you are attempting. I think that is a >>>reasonable thing to say. If you want to accomplish >>>this through a 4xx response, that is actually fine >>>with me. I would like an explicit response code >>>and header (akin to Retry-After) that would allow >>>the server to reject the registration and suggest >>>a more suitable resolution. >>> >>This is a better direction to go. >> > > The problem with returning a new error response > is that non-bis compliant UAC's would reduce the > response to 400. Thus it might actually produce > more registrations and restrict the user from > receiving calls until customer support > communicates what the timer should be. > > The 403 with Expires or a new header could > potentially be used to avoid such a situation. > The UAC could automatically adjust the expiration > or at least communicate the minimum to the user. > The advantage is that older UACs SHOULD NOT > retry the REGISTER without modifying something > (excluding authorization) associated with the > REGISTER request; changing the expiration value > should produce another registration try. > > Taking it one step further, we could add a new > parameter to Contact which could indicate that > the UAC currently does not intend to refresh > the contact beyond the indicated expires value. > This should calm nervous registrars to start > allowing short expiration values under the > pre-text that a 403 would be honored if such > a contact gets refreshed too often. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 20:13:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16745 for ; Thu, 17 Jan 2002 20:13:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA02901 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 20:13:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02019; Thu, 17 Jan 2002 19:49:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01988 for ; Thu, 17 Jan 2002 19:49:20 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16500 for ; Thu, 17 Jan 2002 19:49:18 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0I0nKGe022430; Thu, 17 Jan 2002 19:49:21 -0500 (EST) Message-ID: <3C4770EC.1050204@dynamicsoft.com> Date: Thu, 17 Jan 2002 19:48:44 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Neil Deason CC: sip@ietf.org Subject: Re: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-exist ing Route headers References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Neil Deason wrote: >>Christer Holmberg wrote: > If we have no way of knowing what network SIP will run > over now, or in the future, what is guaranteed to > always be a large enough number? Though this will > create inefficient network usage. It is unclear how > B2BUAs would interact with Max-Forwards headers as they > pass through their UAS|UAC state machine. RFC2543 UAs may > (i.e. will) not typically add in Max-Forwards > RFC 2543 Proxies certainly wont add it where omitted. The same issues arise for IP networks. Their solution is to just have a really big number, 255 in their case. I would not object to a similarly large number, I think 70 should easily suffice. You have to remember that these are going to be extremely unlikely events, so there is little penalty to a larger number in reality. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 20:24:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16888 for ; Thu, 17 Jan 2002 20:24:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA03082 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 20:24:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02148; Thu, 17 Jan 2002 19:58:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02118 for ; Thu, 17 Jan 2002 19:58:21 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16557 for ; Thu, 17 Jan 2002 19:58:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.147]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0I0wJGe022444; Thu, 17 Jan 2002 19:58:21 -0500 (EST) Message-ID: <3C477308.5050601@dynamicsoft.com> Date: Thu, 17 Jan 2002 19:57:44 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Zmolek, Andrew (Andrew)" CC: Neil Deason , sip@ietf.org Subject: Re: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-exist ing Route headers References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Zmolek, Andrew (Andrew) wrote: > If loop detection is not reasonable, it may be still reasonable to make > loop avoidance a topic in the forthcoming implementer's guide. Our > existing PBX product, for instance, initiates a 15-second timer when > forwarding. New calls received within that period are treated as if the > forwarding request were not in place, thus preventing a form of deadly > embrace between the local phone switch and the PBX across all remaining > trunks. I would think a similar solution is applicable to SIP servers, > but as an implementation detail. I think that is a really bad idea for SIP servers. I also think its a bad idea for a PBX, since I do sometimes get two calls within 15s, now you are saying forwarding would not work in that case. Why does it make no sense for a proxy? 1. what is the meaning of NOT forwarding in the case of a proxy??? You are talking about the forwarding FEATURE, here we are talking about the proxy function. The only thing it can do is proxy a request. 2. How does it know that the request received a second time is the same? Your PBX probably looks at DNIS or something. This is equivalent to looking at the request-URI in SIP, and checking if there is another transaction in progress for that same r-uri. This would require an additional mapping of all transactions using purely the r-uri as the key. The alternative is to include the original r-uri in a hash in the via, and then, well, we are right back to the originally specified algorithm. That said, in all honesty, nothing prevents a proxy from doing loop detection, since its a matter of local policy in any case. However, we are trying to simplify, remove and cleanse, and this is something for which there is a far simpler, well understood, and sufficient (given the probabilities of ocurrence). It is easy to do wrong, which has been a source of constant errors. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 21:21:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17700 for ; Thu, 17 Jan 2002 21:21:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA05270 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 21:21:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04362; Thu, 17 Jan 2002 20:56:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04332 for ; Thu, 17 Jan 2002 20:56:30 -0500 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17299 for ; Thu, 17 Jan 2002 20:56:27 -0500 (EST) Received: from localhost (rmahy@localhost) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA17208; Thu, 17 Jan 2002 17:55:58 -0800 (PST) Date: Thu, 17 Jan 2002 17:55:57 -0800 (PST) From: Rohan Mahy X-X-Sender: rmahy@lint.cisco.com To: sip@ietf.org cc: jdrosen@dynamicsoft.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] Comments on "unify" draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Below are some comments in no particluar order on: http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt 1) Page 17 2nd paragraph discusses the benefit of communicating progress of a forked request from each UAS all the way back to the UAC. There are potentially serious privacy concerns here. I would like to see these addressed. Specifically, it should be none of the UACs business if one of the branches returns a 486 Busy Here. 2) It may seem obvious, but it would be nice to mention that this proposal only solves the HERFP problem for dialogs initiated with INVITE. you may want to summarize the proposed solution for other dialog initiating methods (ban forking for that method or define a method for returning the equivalent of 155). 3) Page 26 2nd to last para: should clarify that Content-Dispo preconditions would have to be replaced with Require: preconditions 4) In Figure 12 on modifying codecs (could also apply to declining or switching ports for forked early media), I see no reason why the new offer/answer can't get sent on the PRACK/200 instead of a separate COMET/200. In fact, this meets all the requirements for a general offer/answer model given on Page 16 of the draft. You could also take advantage of *answers* in PRACKs to speed up 3pcc flows. 5) I don't like reusing the COMET method name. I like "UPDATE" because it updates session state, and it can't confuse UAs that support manyfolks. 5) I'm a bit unclear on the proxy behavior proposed for 155. If all UAs supported 155 we wouldn't need to do anything special on a proxy. However, what do we if one of the UASs doesn't support 155. It would return a 420. Is the proxy required to do anything new with this? I could imagine a proxy packaging the response up and sending back to the UAC as a 155, but then the dialog state is out of sync. Perhaps the proxy should send 4xx errors back to the UAC in a COMET (er.. UPDATE!) message? 6) I think correlating offers and answers could get really ugly unless we come up with a simpler correlation mechanism (especially if intermediaries (like ALGs or B2BUAs) are involved. I propose that we add two parameters to the SDP MIME type: sdp-params = ( offer | answer ) offer = "offer" EQUAL sequence-number answer = "answer" EQUAL tag so a complex offer/asnwer dialog might look like this: application/sdp;offer=1 first offer for this dialog application/sdp;offer=1;answer=7839748 answer from 7839748 for this offer ...;offer=1;answer=093412 different answer from another UAS ...;offer=2 a new offer ...;offer=2;answer=093412 answer for this offer etc... comments/flames welcome 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 daemon@optimus.ietf.org Thu Jan 17 21:36:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18904 for ; Thu, 17 Jan 2002 21:36:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA05867 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 21:36:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05038; Thu, 17 Jan 2002 21:05:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05013 for ; Thu, 17 Jan 2002 21:05:21 -0500 (EST) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17528 for ; Thu, 17 Jan 2002 21:05:18 -0500 (EST) Received: from localhost (rmahy@localhost) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA22868; Thu, 17 Jan 2002 18:04:49 -0800 (PST) Date: Thu, 17 Jan 2002 18:04:49 -0800 (PST) From: Rohan Mahy X-X-Sender: rmahy@lint.cisco.com To: sip@ietf.org cc: jdrosen@dynamicsoft.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] re: open issue #290: registrar increasing lifetime Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan sent this message... Clarifying question inline.. -------------------------------------------------------------------------------- I would really like to resolve this one finally. From what I can tell, people seem to agree that, generally speaking, the registrar shouldn't increase it, and if the interval is too low, it can reject it. Brett's concern is backwards compatibility. However, I think I have an easier answer for that. I suspect there are zero existing UA's that ever include an expires less than one hour. So, as long as we mandate that a proxy support registrations of at least one hour (i.e., it not reject registrations greater than one hour because they are too short), we'll be backwards compatible in practice. So, to summarize: 1. registrars can't increase the interval 2. registrars must not reject registrartions less than one hour 3. registrars may reject registrations less that one hour, with some TBD response code ***Rohan*** I agree with 1 and 3, but 2 and 3 are contradictory. ?? May I please hear a yea/nea from the people in this thread?? -Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 22:29:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19688 for ; Thu, 17 Jan 2002 22:29:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA07608 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 22:29:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06472; Thu, 17 Jan 2002 22:00:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06435 for ; Thu, 17 Jan 2002 22:00:10 -0500 (EST) Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19221 for ; Thu, 17 Jan 2002 22:00:07 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g0I2wpC11296 for ; Thu, 17 Jan 2002 21:58:51 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id g0I2wpT11292 for ; Thu, 17 Jan 2002 21:58:51 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: RE: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-existing Route headers Date: Thu, 17 Jan 2002 20:00:40 -0700 Message-ID: Thread-Topic: Deprecate loop detection, was: Re: [Sip] bis draft: Pre-exist ing Route headers Thread-Index: AcGfuzoW9urxILf5RuCsnTjbVeLJwAAD3epw From: "Zmolek, Andrew (Andrew)" To: "Jonathan Rosenberg" Cc: "Neil Deason" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA06436 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Jonathan said: > 2. How does it know that the request received a second time is the same? > Your PBX probably looks at DNIS or something. This is equivalent to Actually, the PBX often has no way of knowing that a loop is happening when it gets locked into a situation where two switches are forwarding to each other. Some older (but well-used) trunk types don't present DNIS, and even on ISDN it can be unreliable. The point is that there are forwarding loop cases that are almost impossible to avoid (particularly when gatewaying is involved), and this 15-second hack prevents a pretty easy PBX DoS attack. Would a gatewayed SIP environment be any smarter about this when there are two gateways forwarding to each other? > looking at the request-URI in SIP, and checking if there is another > transaction in progress for that same r-uri. This would require an > additional mapping of all transactions using purely the r-uri as the >key. The alternative is to include the original r-uri in a hash in the via, and then, well, we are right back to the originally specified algorithm. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 17 22:31:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20256 for ; Thu, 17 Jan 2002 22:31:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA08021 for sip-archive@odin.ietf.org; Thu, 17 Jan 2002 22:31:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06909; Thu, 17 Jan 2002 22:06:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06878 for ; Thu, 17 Jan 2002 22:06:27 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19296 for ; Thu, 17 Jan 2002 22:06:24 -0500 (EST) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g0I36QJ19516; Thu, 17 Jan 2002 22:06:26 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time Date: Thu, 17 Jan 2002 22:08:50 -0500 Message-ID: <000301c19fcd$74acac70$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3C4769B9.6020501@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I suspect there are zero existing UA's that > ever include an expires less than one hour. I am aware of some that allow configuration values of less than one minute (even without clear indication that the units are in seconds). > So, to summarize: > > 1. registrars can't increase the interval > 2. registrars must not reject registrartions > less than one hour I assume you meant 'more' instead of 'less' in the above sentence? > 3. registrars may reject registrations less > that one hour, with some TBD response code Registrars choosing to return this, would break Robert's example of using the REGISTER's expiration for indicating temporarily reach me on conference room phone. However I guess that would be the registrar's decision to bar such an example or expose itself to incorrect/malicious provisioning of a device. > May I please hear a yea/nea from the people > in this thread?? Sounds fine to me. Can the bis please suggest what should happen when a 400 response is received for a REGISTER? This maybe would give a little encouragement to vendors to quit retrying or back off to retrying no more than once every 30 minutes after getting a few 400's (or unknown 4xx's). I mention it in case item 3 turns a new response code instead of a 403. -- Warning the following is completely unrelated -- to the thread but is similar to the above -- suggestion; so if you respond to it, -- please start a new thread since I'm -- not intending to sidetrack this one. Can the bis please suggest what should happen when a 401 response is received for a REGISTER when the UAC can't generate an Authorization header for the challenge? This maybe would give a little encouragement to vendors to quit retrying or back off to no more frequent than once every 30 minutes. Some like to ping-pong the REGISTER (without Authorization header) and 401 until the registrar returns a 403, 404, 405, or 501. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 01:41:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23886 for ; Fri, 18 Jan 2002 01:41:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26076 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 01:41:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19643; Fri, 18 Jan 2002 01:07:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19589 for ; Fri, 18 Jan 2002 01:07:47 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23604 for ; Fri, 18 Jan 2002 01:07:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0I67nGe022551; Fri, 18 Jan 2002 01:07:50 -0500 (EST) Message-ID: <3C47BB91.7040306@dynamicsoft.com> Date: Fri, 18 Jan 2002 01:07:13 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: open issue #290: registrar increasing lifetime Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Correction inline.... Rohan Mahy wrote: > Jonathan sent this message... > Clarifying question inline.. > ------------------------------------------------------------------------ > -------- > > I would really like to resolve this one finally. > > From what I can tell, people seem to agree that, > generally speaking, the registrar shouldn't > increase it, and if the interval is too low, > it can reject it. > > Brett's concern is backwards compatibility. However, > I think I have an easier answer for that. > > > I suspect there are zero existing UA's that ever include > an expires less than one hour. So, as long as we mandate > that a proxy support registrations of at least one > hour (i.e., it not reject registrations greater than one hour > because they are too short), we'll be backwards compatible in practice. > > So, to summarize: > > 1. registrars can't increase the interval > 2. registrars must not reject registrartions less than > one hour Oops, I meant greater than or equal to one hour. > 3. registrars may reject registrations less that one > hour, with some TBD response code > > ***Rohan*** I agree with 1 and 3, but 2 and 3 are contradictory. ?? Yup, sorry bout that. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 01:51:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24073 for ; Fri, 18 Jan 2002 01:51:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26230 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 01:51:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25241; Fri, 18 Jan 2002 01:22:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25212 for ; Fri, 18 Jan 2002 01:22:44 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23670 for ; Fri, 18 Jan 2002 01:22:42 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0I6MMio027521; Fri, 18 Jan 2002 08:22:22 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15431.48926.519889.351332@harjus.eng.song.fi> Date: Fri, 18 Jan 2002 08:22:22 +0200 To: Jonathan Rosenberg Cc: "Henning G. Schulzrinne" , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL In-Reply-To: <3C4751B1.8040208@dynamicsoft.com> References: <3C34C2AD.3000301@dynamicsoft.com> <3C4751B1.8040208@dynamicsoft.com> X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > 2. in the absence of any specific policy or indications on how to > interpret an address, it is RECOMMENDED that it be used to generate a > SIP URL, with that value in the user part, and the domain equal to that > of the provider for the UA. This allows the information to be > interpreted by the user's provider. it is not clear to me what "domain of the provider of the ua" means. one could interpret it to mean the domain of the ip host of the ua. i would rather like to interpret it to mean the domain of the identity that i used when i configured the ua or, in case of soft ua, when i started the ua. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 02:33:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03029 for ; Fri, 18 Jan 2002 02:33:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA28636 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 02:33:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27551; Fri, 18 Jan 2002 02:12:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27520 for ; Fri, 18 Jan 2002 02:12:18 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02657 for ; Fri, 18 Jan 2002 02:12:15 -0500 (EST) Received: from madrid.ericsson.se (madrid.es.eu.ericsson.se [159.107.53.220]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0I7CEJ02530; Fri, 18 Jan 2002 08:12:15 +0100 (MET) Received: from lmf.ericsson.se by madrid.ericsson.se (SMI-8.6/SMI-SVR4) id IAA27806; Fri, 18 Jan 2002 08:12:03 +0100 Message-ID: <3C47CAC4.CDE24EE1@lmf.ericsson.se> Date: Fri, 18 Jan 2002 09:12:04 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Henning G. Schulzrinne" , Dorgham Sisalem , sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <3C388ED4.19AB555D@cs.columbia.edu> <3C473C59.6010405@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Just a small comment on point (1). A case where the response may be much bigger than the request is when we send an INVITE without SDP, and receive a 200 with SDP. Now, I am NOT saying this is a problem, and it could probably also be classified as "in most cases it won't happen". At least I can't remember when I would have seen it in a real-life scenario. But, maybe people doing SIP/H.323 interworking have some info on this? Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > I've been working through the various possibilities with Henning. Our > conclusion is that any of these redirect-to-tcp mecahnisms are frought > with problems. > > Therefore, the proposal is the following: > > 1. if the request is larger than some threshold (1000 or somehting), you > MUST use TCP (after compression, of course). If the path MTU is known, > you need to use TCP if the request is greater than that value - 300 or so. > > 2. It is RECOMMENDED to use TCP to communicate with a server when you > know a NAT is in the way. > > Point (1) is based on the observation that in most cases, the response > is not substanially larger than the request. This is certainly true for > MESSAGE, BYE. It is not true for OPTIONS, admittedly, but those are not > record-routed and the requests are also ususally small. The main item > will be record-routes, which can be many hundreds of bytes. Therefore, > we leave a bit of buffer space in the threshold to account for that. > Thus, we should be OK. The second point ensures that, if fragmentation > of the response does happen, there hopefully isn't a nat in the way, > since that is the really bad case. > > A refinement on this is what will go into bis-06 unless someone has a > really big beef with it. > > -Jonathan R. > > Henning G. Schulzrinne wrote: > > > Dorgham Sisalem wrote: > > > >>Hello, > >> looking at all the complexity of 499 and UDP to TCP transition I am > >> wondering if fragmentation is really worth the trouble. For the case > >> of signaling I hardly imagine the messages will get big enough so as > >> to worry about congestion due to retransmission (just because a SIP > >> > > > > I think the congestion aspect deserves an additional sentence or two. > > Effectively, SIP behaves like TCP with a window size of 1 segment and > > only time-out based retransmission, i.e., the most conservative > > operational mode of TCP. Depending on the RTT estimate, the SIP timers > > will obviously differ, but their growth behavior is also similar. > > > > The main problem is that with fragmentation, SIP may fail completely if > > various NATs and firewalls get in the way. That, in my view, is the > > bigger issue. > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 05:48:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05979 for ; Fri, 18 Jan 2002 05:48:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA04785 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 05:48:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03636; Fri, 18 Jan 2002 05:23:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03599 for ; Fri, 18 Jan 2002 05:23:42 -0500 (EST) Received: from youwin ([211.174.76.129]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05543 for ; Fri, 18 Jan 2002 05:23:36 -0500 (EST) Message-Id: <200201181023.FAA05543@ietf.org> Reply-To: jarrylove@hanmail.net From: ¾ÆÀÌ·¯ºêÀ×±Û¸®½¬ To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 18 Jan 2002 19:19:55 +0900 Subject: [Sip] [±¤°í] Èû°Ü¿ü´ø ¿µ¾î! ÀÌÁ¦ ´Ù½Ã ½ÃÀÛÇϽʽÿÀ. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org µÉ¼ö¹Û¿¡ ¾ø´Â ¿µ¾î - ¾ÆÀÌ·¯ºêÀ×±Û¸®½¬

YTN ´º½º º¸±â

Ç÷¡½¬ ¾Ö´Ï¸ÅÀÌ¼Ç º¸±â


Çã¶ô¾øÀÌ ¸ÞÀÏÀ» µå·Á ´ë´ÜÈ÷ Á˼ÛÇÕ´Ï´Ù.
(¿øÇÏÁö ¾ÊÀ¸½Ã¸é ¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ ÇØÁֽʽÿÀ ) ¼ö½Å °ÅºÎ

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 09:34:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12575 for ; Fri, 18 Jan 2002 09:34:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA14810 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 09:34:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13529; Fri, 18 Jan 2002 09:07:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13504 for ; Fri, 18 Jan 2002 09:07:42 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11340 for ; Fri, 18 Jan 2002 09:07:39 -0500 (EST) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id g0IFAxM07099; Fri, 18 Jan 2002 09:11:00 -0600 Message-ID: <00c201c1a029$430eef00$0a64a8c0@flak> From: "Dean Willis" To: Cc: , , References: <17052388D394D411803900508BDFFAF601B3715E@n0214idc1.oss.level3.com> Subject: Re: [Sip] Attention - comment on Loose Routing draft Date: Fri, 18 Jan 2002 08:05:57 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Changing the request-URI in a reinvite makes it not a reinvite, right? -- Dean ----- Original Message ----- From: To: Cc: ; ; Sent: Thursday, January 17, 2002 9:22 AM Subject: RE: [Sip] Attention - comment on Loose Routing draft > > I would have to disagree with you too. This sounds like trouble brewing, > especially in transactions subsequent to the first. Take for example a > firewall control proxy downstream from X. An initial Invite sets up > firewall resources. If a re-Invite comes through and X decides service > route points downstream from X don't matter anymore, you just stranded > firewall resources. > > John Hearty > Level3 > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, January 17, 2002 3:55 AM > To: Honeisen Bernhard (NET/Helsinki); sip@ietf.org > Cc: 'ext Robert Sparks' > Subject: Re: [Sip] Attention - comment on Loose Routing draft > > > Hmm, RjS may disagree, but I think that the retargeting of the message at X > might override the service routing in the original request. Changing the > request URI means to me "don't send it to where it was being sent, send it > to this other place instead". Given this logic, service route points > downstream from X probably don't matter anymore. > > -- > Dean > > ----- Original Message ----- > From: "Honeisen Bernhard (NET/Helsinki)" > To: > Cc: "'ext Robert Sparks'" > Sent: Tuesday, January 15, 2002 9:05 AM > Subject: RE: [Sip] Attention - comment on Loose Routing draft > > > > Hi RjS! > > > > Some question: > > > > Consider a situation, where a request is directed > > to (B) and two service elements (X) and (Y) have > > to be visited before. > > (X) performs a service, which replaces the intended > > destination URL, i.e. (B), whereas (Y) executes > > some feature, which depends on the output of (X). > > > > When the request arrives at (X), the R-URI / Route > > could look like: > > - R-URI: > > - Route: , > > (The intended destination has been appended earlier > > to Route as per section 5.2 in your I/D) > > > > How can (X) now apply the destination URL relacing feature? > > My first guess was, that (X) would modify the last entry > > in the Route, i.e. (B). > > > > Your first proposal in section 2 prohibits such behavior: > > "[...] an element [...] MUST NOT modify or remove > > subsequent Route header field values." > > > > Is this restriction intended also for such cases or could > > we relax it to allow modifying of the last entry in Route? > > Would marking the last Route entry as the intended > > destination (and allow modifying of such only) solve > > this issue? > > > > Greetings, > > Bernie > > > > > > PS: Some Typos: > > > > - section 5.5, F7-F12: > > s/Contact: sip:jbj@212.28.214.227/Contact: sip:jbj@212.28.214.228/ > > > > - section 5.5. F3/F4: > > - Shouldn't maddr in F4 contain a different IP-address > > than in F3? > > - Maybe add a FQDN <-> IP mapping table to ease > > the understanding of the examples. > > > > - section 5.8: > > s/senting/sending/ > > > > > > > > >-----Original Message----- > > >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > >Sent: 14. January 2002 20:58 > > >To: 'sip@ietf.org' > > >Subject: [Sip] Attention - comment on Loose Routing draft > > > > > > > > >The draft below contains the resolution to a large > > >set of open issues around processing of the Route header, > > >preloaded routes, and the use of default outbound proxies. > > >The plan is to modify bis to reflect these proposals. > > > > > >Please review it as soon as you can and comment if you > > >see real problems. Silence will be taken as consent. > > > > > >RjS > > > > > >> -----Original Message----- > > >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > >> Sent: Thursday, January 10, 2002 10:46 PM > > >> To: 'sip@ietf.org' > > >> Subject: [Sip] Loose Routing draft > > >> > > >> > > >> I just submitted a draft refining the post I sent > > >> out after IETF52 on the loose routing proposal. > > >> > > >> Until it appears in the archive, you can find it at > > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt > > >> or > > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html > > >> > > >> > > >> RjS > > >> > > >> _______________________________________________ > > >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > >> Use sipping@ietf.org for new developments on the application of sip > > >> > > > > > >_______________________________________________ > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >This list is for NEW development of the core SIP Protocol > > >Use sip-implementors@cs.columbia.edu for questions on current sip > > >Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 09:50:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13275 for ; Fri, 18 Jan 2002 09:50:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15190 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 09:50:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13771; Fri, 18 Jan 2002 09:13:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13666 for ; Fri, 18 Jan 2002 09:13:15 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11602 for ; Fri, 18 Jan 2002 09:13:12 -0500 (EST) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id g0IFGfM07126; Fri, 18 Jan 2002 09:16:41 -0600 Message-ID: <00ca01c1a02a$0e3d1800$0a64a8c0@flak> From: "Dean Willis" To: "Juha Heinanen" , "Jonathan Rosenberg" Cc: "Henning G. Schulzrinne" , References: <3C34C2AD.3000301@dynamicsoft.com><3C4751B1.8040208@dynamicsoft.com> <15431.48926.519889.351332@harjus.eng.song.fi> Subject: Re: [Sip] Open Issue #366: sip v. tel URL Date: Fri, 18 Jan 2002 08:11:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit We have here something like the default domain on DNS lookups, or the default domain added by mail systems when one sends mail to an address which doesn't have a host part. Why shouldn't the default domain to added by a SIP phone be a piece of local configuration information, just as it is for mail and DNS? -- Dean ----- Original Message ----- From: "Juha Heinanen" To: "Jonathan Rosenberg" Cc: "Henning G. Schulzrinne" ; Sent: Friday, January 18, 2002 12:22 AM Subject: Re: [Sip] Open Issue #366: sip v. tel URL > Jonathan Rosenberg writes: > > > 2. in the absence of any specific policy or indications on how to > > interpret an address, it is RECOMMENDED that it be used to generate a > > SIP URL, with that value in the user part, and the domain equal to that > > of the provider for the UA. This allows the information to be > > interpreted by the user's provider. > > it is not clear to me what "domain of the provider of the ua" means. > one could interpret it to mean the domain of the ip host of the ua. i > would rather like to interpret it to mean the domain of the identity > that i used when i configured the ua or, in case of soft ua, when i > started the ua. > > -- juha > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 09:53:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13373 for ; Fri, 18 Jan 2002 09:53:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15239 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 09:53:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13901; Fri, 18 Jan 2002 09:19:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13871 for ; Fri, 18 Jan 2002 09:18:58 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11771 for ; Fri, 18 Jan 2002 09:18:55 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0IEIrio027788; Fri, 18 Jan 2002 16:18:53 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15432.11981.90292.43613@harjus.eng.song.fi> Date: Fri, 18 Jan 2002 16:18:53 +0200 To: "Dean Willis" Cc: "Jonathan Rosenberg" , "Henning G. Schulzrinne" , Subject: Re: [Sip] Open Issue #366: sip v. tel URL In-Reply-To: <00ca01c1a02a$0e3d1800$0a64a8c0@flak> References: <3C34C2AD.3000301@dynamicsoft.com> <3C4751B1.8040208@dynamicsoft.com> <15431.48926.519889.351332@harjus.eng.song.fi> <00ca01c1a02a$0e3d1800$0a64a8c0@flak> X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > Why shouldn't the default domain to added by a SIP phone be a piece of local > configuration information, just as it is for mail and DNS? because i can log in to a anybodies sip "phone" sitting in some ip subnet with whatever sip url i hapens to have. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 10:14:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14096 for ; Fri, 18 Jan 2002 10:14:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA16787 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 10:14:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15062; Fri, 18 Jan 2002 09:41:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15028 for ; Fri, 18 Jan 2002 09:41:43 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12845 for ; Fri, 18 Jan 2002 09:41:40 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA09053; Fri, 18 Jan 2002 09:41:38 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0IEfbJ1029738; Fri, 18 Jan 2002 09:41:37 -0500 (EST) Message-ID: <3C483421.8EB14E@cs.columbia.edu> Date: Fri, 18 Jan 2002 09:41:37 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: Juha Heinanen , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C34C2AD.3000301@dynamicsoft.com><3C4751B1.8040208@dynamicsoft.com> <15431.48926.519889.351332@harjus.eng.song.fi> <00ca01c1a02a$0e3d1800$0a64a8c0@flak> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > We have here something like the default domain on DNS lookups, or the > default domain added by mail systems when one sends mail to an address which > doesn't have a host part. Note that these two are typically different if you travel outside your home domain. > > Why shouldn't the default domain to added by a SIP phone be a piece of local > configuration information, just as it is for mail and DNS? I think it would be more precise to simply have one home domain. This domain is used for registrations and, where needed, as the default domain for numbers entered. As Jonathan said, we should keep the number of configuration options that are needed as small as possible. (I'm less worried about parameters that are rarely changed, such as timer values.) In that vain, do we have any notion in the spec as to the list of things that would need to be configured to set up a UA, beyond the home domain? It might be helpful to document this. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 10:29:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14584 for ; Fri, 18 Jan 2002 10:29:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA17385 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 10:29:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16088; Fri, 18 Jan 2002 10:03:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16060 for ; Fri, 18 Jan 2002 10:03:00 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13675 for ; Fri, 18 Jan 2002 10:02:55 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA10602; Fri, 18 Jan 2002 09:59:10 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0IEx9J1000160; Fri, 18 Jan 2002 09:59:09 -0500 (EST) Message-ID: <3C48383D.5B26A3C3@cs.columbia.edu> Date: Fri, 18 Jan 2002 09:59:09 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C34C2AD.3000301@dynamicsoft.com> <3C4751B1.8040208@dynamicsoft.com> <15431.48926.519889.351332@harjus.eng.song.fi> <00ca01c1a02a$0e3d1800$0a64a8c0@flak> <15432.11981.90292.43613@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > Dean Willis writes: > > > Why shouldn't the default domain to added by a SIP phone be a piece of local > > configuration information, just as it is for mail and DNS? > > because i can log in to a anybodies sip "phone" sitting in some ip > subnet with whatever sip url i hapens to have. > To make my proposal more concrete: If I log in as foo@example.com, my home domain is example.com and this home domain will be used for registrations and default domain for E.164 numbers (and maybe for preloaded routes, if that matters). Does that work? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 10:33:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14722 for ; Fri, 18 Jan 2002 10:33:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18172 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 10:33:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16329; Fri, 18 Jan 2002 10:05:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16298 for ; Fri, 18 Jan 2002 10:05:49 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13765 for ; Fri, 18 Jan 2002 10:05:46 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0IF5iio027837; Fri, 18 Jan 2002 17:05:44 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15432.14792.493387.793218@harjus.eng.song.fi> Date: Fri, 18 Jan 2002 17:05:44 +0200 To: "Henning G. Schulzrinne" Cc: Dean Willis , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL In-Reply-To: <3C48383D.5B26A3C3@cs.columbia.edu> References: <3C34C2AD.3000301@dynamicsoft.com> <3C4751B1.8040208@dynamicsoft.com> <15431.48926.519889.351332@harjus.eng.song.fi> <00ca01c1a02a$0e3d1800$0a64a8c0@flak> <15432.11981.90292.43613@harjus.eng.song.fi> <3C48383D.5B26A3C3@cs.columbia.edu> X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning G. Schulzrinne writes: > To make my proposal more concrete: If I log in as foo@example.com, my > home domain is example.com and this home domain will be used for > registrations and default domain for E.164 numbers (and maybe for > preloaded routes, if that matters). Does that work? this would be fine. the text that somone posted didn't make it so clear and that is why i made my comment. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 10:38:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14837 for ; Fri, 18 Jan 2002 10:38:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18387 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 10:38:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16590; Fri, 18 Jan 2002 10:10:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16532 for ; Fri, 18 Jan 2002 10:10:15 -0500 (EST) Received: from mailcity.com (fes-qout.whowhere.com [209.185.123.96]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13986 for ; Fri, 18 Jan 2002 10:10:12 -0500 (EST) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri Jan 18 07:09:34 2002 To: "SIP Implementors Group" , "SIP List" , "SIP" , "SIP-NG" Date: Fri, 18 Jan 2002 10:09:34 -0500 From: "Info Van" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: infovaan@lycos.com X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 64.66.32.130 Organization: Lycos Mail (http://mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] how do we handle 911 call originated by SIP user? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit hi, for SIP->PSTN call, is there any ID or any other work-in-progress, any suggestion, as to how do we handle SIP->911 calls ?? the problem as i see it :- 1) SIP user can log on from any domain (and be a dial-up user who get's a new IP everytime) 2) SIP UA currently doesn't seem to have any MANDATORY "geographic-location" (not necessarily GPS based, but say "postal address based") location information that can be relayed onto the PSAP. 3) SIP user could be a mobile-IP user where finding out location and IP bindings i believe is very costly!! (not sure on that). how do we plan to handle this ? i know this is a problem we've lived with in 2-2.5G Mobile networks (and found some solutions too), but i don't see any "triangulation" out here... obviously implementors, network operators would be mandated by FCC regs. to provide 911... so... how does the SIP-ASP (service provider) make sure that the UA's like Pingtel, HearMe or any other co. provide location info, without standardizing it...?? i'm sure this has been discussed (but not sure if it's been solved and taken care of) already... sorry for cross-posting, but i thought it right because i wasn't sure if this is a future-work, work-in-progress, or under-implementation (could be all the 3). thanks for any/all inputs, bdutta. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 10:48:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15405 for ; Fri, 18 Jan 2002 10:48:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18867 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 10:48:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17191; Fri, 18 Jan 2002 10:22:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17155 for ; Fri, 18 Jan 2002 10:22:20 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14408 for ; Fri, 18 Jan 2002 10:22:17 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0IFJrkN003398; Fri, 18 Jan 2002 10:19:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 10:21:41 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9A6@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , brett@broadsoft.com Cc: sip@ietf.org Subject: RE: [Sip] Open Issue #290: Registrar increasing registration life time Date: Fri, 18 Jan 2002 10:21:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm ok with this. I have a comment and a request below. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, January 17, 2002 6:18 PM > To: brett@broadsoft.com > Cc: sip@ietf.org > Subject: Re: [Sip] Open Issue #290: Registrar increasing registration > life time > > > I would really like to resolve this one finally. > > From what I can tell, people seem to agree that, > generally speaking, the registrar shouldn't > increase it, and if the interval is too low, > it can reject it. > > Brett's concern is backwards compatibility. However, > I think I have an easier answer for that. > > > I suspect there are zero existing UA's that ever include > an expires less than one hour. So, as long as we mandate > that a proxy support registrations of at least one > hour (i.e., it not reject registrations greater than one hour > because they are too short), we'll be backwards compatible in > practice. > > So, to summarize: > > 1. registrars can't increase the interval > 2. registrars must not reject registrartions less than > one hour As you already pointed out, you mean more than one hour here. It would be good to specifically capture that registrars mustn't reject the request only because they wanted the expiration to be longer (we still want to be able to return 401s, 503s, etc). I would ask to make this a SHOULD and not a MUST. In no version of the spec to date has there been a requirement that I, as a registrar, MUST accept a registration of a given duration - I've always had the option to refuse it if it violated some policy of mine. A MUST here also builds another good candidate for future-failure (those places where we have pain fixing problems in the future because of backwards compatibility). Do you really want to close off the functionality of the TBD response below to long expirations forever? Or would it be better to recommend the hour threshold and have implementors anticipating change? That said, don't hold up closing it based on these comments. > 3. registrars may reject registrations less that one > hour, with some TBD response code > > May I please hear a yea/nea from the people in this thread?? > > -Jonathan R. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 10:58:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15855 for ; Fri, 18 Jan 2002 10:58:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19304 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 10:58:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17568; Fri, 18 Jan 2002 10:30:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17502 for ; Fri, 18 Jan 2002 10:30:23 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14632; Fri, 18 Jan 2002 10:30:19 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA13806; Fri, 18 Jan 2002 10:30:20 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0IFUKJ1001301; Fri, 18 Jan 2002 10:30:20 -0500 (EST) Message-ID: <3C483F8B.FB5BDEA9@cs.columbia.edu> Date: Fri, 18 Jan 2002 10:30:19 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: infovaan@lycos.com CC: SIP Implementors Group , SIP List , SIP , SIP-NG Subject: Re: [Sip] how do we handle 911 call originated by SIP user? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit A new draft on this is in progress. I think there will be several stages of solutions, depending on what kind of external infrastructure is available or might be available in the future. I don't know if this is an official work item of the SIPPING group yet. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 10:58:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15890 for ; Fri, 18 Jan 2002 10:58:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19332 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 10:58:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17050; Fri, 18 Jan 2002 10:20:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17020 for ; Fri, 18 Jan 2002 10:20:40 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14295 for ; Fri, 18 Jan 2002 10:20:36 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id PAA10987; Fri, 18 Jan 2002 15:19:19 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id PAA15754; Fri, 18 Jan 2002 15:20:30 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 08:20:30 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B37166@n0214idc1.oss.level3.com> To: dean.willis@softarmor.com Cc: rsparks@dynamicsoft.com, bernhard.honeisen@nokia.com, sip@ietf.org Subject: RE: [Sip] Attention - comment on Loose Routing draft Date: Fri, 18 Jan 2002 08:20:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The UAC considers it a re-Invite even when a proxy later re-writes the r-uri (a common action). I'm not clear where you are headed with this line of thought wrt Robert's draft. John Hearty Level3 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Friday, January 18, 2002 7:06 AM To: Hearty, John Cc: rsparks@dynamicsoft.com; bernhard.honeisen@nokia.com; sip@ietf.org Subject: Re: [Sip] Attention - comment on Loose Routing draft Changing the request-URI in a reinvite makes it not a reinvite, right? -- Dean ----- Original Message ----- From: To: Cc: ; ; Sent: Thursday, January 17, 2002 9:22 AM Subject: RE: [Sip] Attention - comment on Loose Routing draft > > I would have to disagree with you too. This sounds like trouble brewing, > especially in transactions subsequent to the first. Take for example a > firewall control proxy downstream from X. An initial Invite sets up > firewall resources. If a re-Invite comes through and X decides service > route points downstream from X don't matter anymore, you just stranded > firewall resources. > > John Hearty > Level3 > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, January 17, 2002 3:55 AM > To: Honeisen Bernhard (NET/Helsinki); sip@ietf.org > Cc: 'ext Robert Sparks' > Subject: Re: [Sip] Attention - comment on Loose Routing draft > > > Hmm, RjS may disagree, but I think that the retargeting of the message at X > might override the service routing in the original request. Changing the > request URI means to me "don't send it to where it was being sent, send it > to this other place instead". Given this logic, service route points > downstream from X probably don't matter anymore. > > -- > Dean > > ----- Original Message ----- > From: "Honeisen Bernhard (NET/Helsinki)" > To: > Cc: "'ext Robert Sparks'" > Sent: Tuesday, January 15, 2002 9:05 AM > Subject: RE: [Sip] Attention - comment on Loose Routing draft > > > > Hi RjS! > > > > Some question: > > > > Consider a situation, where a request is directed > > to (B) and two service elements (X) and (Y) have > > to be visited before. > > (X) performs a service, which replaces the intended > > destination URL, i.e. (B), whereas (Y) executes > > some feature, which depends on the output of (X). > > > > When the request arrives at (X), the R-URI / Route > > could look like: > > - R-URI: > > - Route: , > > (The intended destination has been appended earlier > > to Route as per section 5.2 in your I/D) > > > > How can (X) now apply the destination URL relacing feature? > > My first guess was, that (X) would modify the last entry > > in the Route, i.e. (B). > > > > Your first proposal in section 2 prohibits such behavior: > > "[...] an element [...] MUST NOT modify or remove > > subsequent Route header field values." > > > > Is this restriction intended also for such cases or could > > we relax it to allow modifying of the last entry in Route? > > Would marking the last Route entry as the intended > > destination (and allow modifying of such only) solve > > this issue? > > > > Greetings, > > Bernie > > > > > > PS: Some Typos: > > > > - section 5.5, F7-F12: > > s/Contact: sip:jbj@212.28.214.227/Contact: sip:jbj@212.28.214.228/ > > > > - section 5.5. F3/F4: > > - Shouldn't maddr in F4 contain a different IP-address > > than in F3? > > - Maybe add a FQDN <-> IP mapping table to ease > > the understanding of the examples. > > > > - section 5.8: > > s/senting/sending/ > > > > > > > > >-----Original Message----- > > >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > >Sent: 14. January 2002 20:58 > > >To: 'sip@ietf.org' > > >Subject: [Sip] Attention - comment on Loose Routing draft > > > > > > > > >The draft below contains the resolution to a large > > >set of open issues around processing of the Route header, > > >preloaded routes, and the use of default outbound proxies. > > >The plan is to modify bis to reflect these proposals. > > > > > >Please review it as soon as you can and comment if you > > >see real problems. Silence will be taken as consent. > > > > > >RjS > > > > > >> -----Original Message----- > > >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > >> Sent: Thursday, January 10, 2002 10:46 PM > > >> To: 'sip@ietf.org' > > >> Subject: [Sip] Loose Routing draft > > >> > > >> > > >> I just submitted a draft refining the post I sent > > >> out after IETF52 on the loose routing proposal. > > >> > > >> Until it appears in the archive, you can find it at > > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt > > >> or > > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html > > >> > > >> > > >> RjS > > >> > > >> _______________________________________________ > > >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > >> Use sipping@ietf.org for new developments on the application of sip > > >> > > > > > >_______________________________________________ > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >This list is for NEW development of the core SIP Protocol > > >Use sip-implementors@cs.columbia.edu for questions on current sip > > >Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 11:23:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17128 for ; Fri, 18 Jan 2002 11:23:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20897 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 11:24:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19222; Fri, 18 Jan 2002 10:56:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19191 for ; Fri, 18 Jan 2002 10:56:52 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15752 for ; Fri, 18 Jan 2002 10:56:48 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0IFsXkN003504 for ; Fri, 18 Jan 2002 10:54:33 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 18 Jan 2002 10:56:21 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9A7@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Fri, 18 Jan 2002 10:56:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Issues with telephone-subscriber appearing in a SIP URI. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org A SIP URI can contain a rfc2806(tel URL) telephone-subscriber in the userpart of the URI. Previous discussions have made it clear that tel-url parameters are placed in the userpart of their sip counterparts. There has been some discussion in the past on how this interacts with URI equality. To summarize - These tel URIs are equivalent: tel:+122;parm1=val1;parm2=val2 tel:+122;parm1=VAL1;PARM2=val2 tel:+122;parm2=val2;parm1=val1 But no two of these SIP URIs are equivalent: sip:+122;parm1=val;parm2=val2@somewhere.net;user=phone sip:+122;parm1=VAL1;PARM2=val2@somewhere.net;user=phone sip:+122;parm2=val2;parm1=val1@somewhere.net;user=phone because the userpart of SIP URIs is compared case-sensitive. A few ways of addressing this have been kicked around. To summarize: 1) Mandate that ;user=phone appears if and only if the userpart of a SIP URI is formed as a telephone-subscriber. This would, in my opinon, be a very bad thing to do. It effectively makes parsing tel: URLs mandatory (except for the "tel:" string) and would force every SIP element to look for and parse the user parameter before it could even begin to look at the userpart. There are many SIP elements that are never going to care, and should be treating the userpart as an opaque string. 2) Move the tel URI parameters off into the SIP URI parameter space. This has been discussed and refused before on the SIP lists. Among other things, you get into problems with collisions in the parameter name space. 3) Accept and document the limitation. This is the approach the group has been leaning towards. To make things better, I would like to add to this that we suggest a canonical form for the userpart of a SIP URI when it is a telephone-subscriber. Specifically, such userparts SHOULD be formed folded to lower-case, with the parameters ordered lexically by parameter name. Only elements that create such URIs need to know how to do this - all other elements can continue to treat the userpart as a blob. Comments? In absence of contrary discussion, I will reflect 3) in bis-06. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 11:26:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17197 for ; Fri, 18 Jan 2002 11:26:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20997 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 11:26:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19490; Fri, 18 Jan 2002 11:00:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19451 for ; Fri, 18 Jan 2002 11:00:11 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16026 for ; Fri, 18 Jan 2002 11:00:07 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0IFvJkN003519; Fri, 18 Jan 2002 10:57:19 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 10:59:07 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9A8@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Henning G. Schulzrinne'" , Anders Kristensen Cc: sip@ietf.org Subject: RE: [Sip] Open issue #100: case sensitivity of URL parameter valu es Date: Fri, 18 Jan 2002 10:59:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org To follow up and close this thread: bis-06 will state The userpart of a SIP URI is compared case sensitive. All other components are compared case-insensitive unless the definition of the component specifies otherwise. RjS > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, September 26, 2001 7:32 PM > To: Anders Kristensen > Cc: sip@ietf.org > Subject: Re: [Sip] Open issue #100: case sensitivity of URL parameter > values > > > Anders Kristensen wrote: > > > > > The parts defining individual parameters say whether the > *value* of that > > param is CS or not. My reading is that param names always are CS. > > Unfortunately, the HTTP URL doesn't seem to have parameters (as in > ;foo=bar). > > Just to be sure we're talking about the same thing: there are two > parameters in SIP, the URL parameters (like transport and > maddr) and the > header parameters (as those found in abundance in the Contact header > definition). There is no strict necessity that the two are treated the > same. It is, unfortunately, not even clear whether header parameters > (such as the 'q' parameter in HTTP) are CI or CS, although it is quite > possible that I overlooked some statement in 2616 to that effect. > > I just looked at 2617 (Basic and Digest Authentication), since it has > lots of parameters. According to Section 1.2: > > The realm directive (case-insensitive) is required for all > authentication schemes that issue a challenge. The realm value > (case-sensitive), ... > > Thus, this is a case where the parameter name (realm, in this case) is > CI. The other parameters in 2617 don't seem to say. > > However, according to the BNF, > > "literal" > Quotation marks surround literal text. Unless stated otherwise, > the text is case-insensitive. > > Thus, all the others are also CI. > > It would be helpful if we can get further evidence of common > practice in > HTTP, SMTP or kin. > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 11:32:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17516 for ; Fri, 18 Jan 2002 11:32:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21576 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 11:32:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19969; Fri, 18 Jan 2002 11:03:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19940 for ; Fri, 18 Jan 2002 11:03:10 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16239 for ; Fri, 18 Jan 2002 11:03:07 -0500 (EST) Received: from zipper.cisco.com (zipper.cisco.com [171.69.25.142]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0IG2dA02743; Fri, 18 Jan 2002 08:02:39 -0800 (PST) Date: Fri, 18 Jan 2002 08:02:38 -0800 (PST) From: Rohan Mahy To: cc: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] "unify" draft: problem with upstream 407 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I noticed another issue with the proposed HERFP solution in the unify draft with respect to upstream 407s. suppose UA A sends to Proxy 1 which forks to b@domain1 and c@domain2 to get to c@domain2 the request is routed through a non-forking proxy (Proxy 2) which sends a 407. How is this response handled? - it doesn't seem that proxy 2 could send a 155 since it probably isn't capable of receiving a COMET and forwarding an INVITE (breaks idempotency) - proxy 2 could send a 407, which proxy 1 packages in a 155, UA A sends a COMET, proxy 1 sends a new INVITE (same CSeq new branch)... Looking carefully at the status codes, the proposed HERFP solution works perfectly with 1xx, 2xx, and 6xx responses because it doesn't change any behavior there. It works fine with 3xx if recursion is turned on. It works fine for 5xx with the possible exception of 513 (presumably you could strip some crud and try to send a smaller message, but that is not a great loss). The 4xx responses seem to fall into 3 categories: 1) there is no recourse if the branch fails, so retrying is irrelevant: 400, 403, 404, 408, 410, 414, 421, 481, 482, 483, 486, 487, 405?, 406?, 480? 2) if the branch fails, you could use a 155 and expect recourse with a COMET: 401, 402, 488, and possibly 415? 3) if the branch fails it is unlikely that you can fix the problem with a COMET, but you could (at least theoretically) fix the problem with a new INVITE: 407, 420, 484 (no great loss when forking), 485, and 413? comments? suggestions? proposals? 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 daemon@optimus.ietf.org Fri Jan 18 11:36:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17674 for ; Fri, 18 Jan 2002 11:36:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA21703 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 11:36:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20042; Fri, 18 Jan 2002 11:03:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19989 for ; Fri, 18 Jan 2002 11:03:49 -0500 (EST) Received: from mailcity.com (fes-qout.whowhere.com [209.185.123.96]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16274 for ; Fri, 18 Jan 2002 11:03:46 -0500 (EST) Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Fri Jan 18 08:03:06 2002 To: infovaan@lycos.com, "Henning G. Schulzrinne" Date: Fri, 18 Jan 2002 11:03:06 -0500 From: "Info Van" Message-ID: Mime-Version: 1.0 Cc: "SIP Implementors Group" , "SIP List" , "SIP" , "SIP-NG" X-Sent-Mail: on Reply-To: infovaan@lycos.com X-Mailer: MailCity Service X-Priority: 3 X-Sender-Ip: 64.66.32.130 Organization: Lycos Mail (http://mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] how do we handle 911 call originated by SIP user? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit great. where (if any) discussions on this are taking place ? one thing though... whatever infrastructure we have in future, (i am not sure what all is being considered), but we'd still be stuck with "legacy" SIP UA's... which might be difficult to upgrade (or too costly to upgrade with newer technology)...!! so i was thinking, isn't it better to make the solution free (or separate) from infrastructure (s.a. GPS for e.g.). how about a simple solution s.a. (i know it's implementation and it's requirement would be something, not in line with IEFT work, maybe). a user logging-in to a UA (before originating a SIP call), needs to supply (or select from a list, or say "YES" to an option to pick) a postal address (or geographic location), which says is stored by UA, (until it's revoked or expired) and conveyed in an INVITE in a MANDATORY header ?? say sometime like GeoLocation: or something !!! thanks, banibrata dutta. --- On Fri, 18 Jan 2002 10:30:19 Henning G. Schulzrinne wrote: >A new draft on this is in progress. I think there will be several stages >of solutions, depending on what kind of external infrastructure is >available or might be available in the future. I don't know if this is >an official work item of the SIPPING group yet. >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 12:20:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19487 for ; Fri, 18 Jan 2002 12:20:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24936 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 12:21:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22080; Fri, 18 Jan 2002 11:49:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22052 for ; Fri, 18 Jan 2002 11:49:00 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18317 for ; Fri, 18 Jan 2002 11:48:56 -0500 (EST) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id g0IGmqM07849; Fri, 18 Jan 2002 10:48:53 -0600 Message-ID: <004901c1a03f$d31ecf00$0a64a8c0@flak> From: "Dean Willis" To: "Henning G. Schulzrinne" Cc: "Juha Heinanen" , "Jonathan Rosenberg" , References: <3C34C2AD.3000301@dynamicsoft.com><3C4751B1.8040208@dynamicsoft.com> <15431.48926.519889.351332@harjus.eng.song.fi> <00ca01c1a02a$0e3d1800$0a64a8c0@flak> <3C483421.8EB14E@cs.columbia.edu> Subject: Re: [Sip] Open Issue #366: sip v. tel URL Date: Fri, 18 Jan 2002 10:47:30 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Depends on how they're configured. My email client never changes the default domain it appends. The default domain for lookups only changes if I set my dhcp client to overwrite /etc/resolv.conf. -- Dean ----- Original Message ----- From: "Henning G. Schulzrinne" To: "Dean Willis" Cc: "Juha Heinanen" ; "Jonathan Rosenberg" ; Sent: Friday, January 18, 2002 8:41 AM Subject: Re: [Sip] Open Issue #366: sip v. tel URL > Dean Willis wrote: > > > > We have here something like the default domain on DNS lookups, or the > > default domain added by mail systems when one sends mail to an address which > > doesn't have a host part. > > Note that these two are typically different if you travel outside your > home domain. > > > > > Why shouldn't the default domain to added by a SIP phone be a piece of local > > configuration information, just as it is for mail and DNS? > > I think it would be more precise to simply have one home domain. This > domain is used for registrations and, where needed, as the default > domain for numbers entered. As Jonathan said, we should keep the number > of configuration options that are needed as small as possible. (I'm less > worried about parameters that are rarely changed, such as timer values.) > > In that vain, do we have any notion in the spec as to the list of things > that would need to be configured to set up a UA, beyond the home domain? > It might be helpful to document this. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 12:28:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19754 for ; Fri, 18 Jan 2002 12:28:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25153 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 12:28:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21887; Fri, 18 Jan 2002 11:45:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21856 for ; Fri, 18 Jan 2002 11:45:00 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18116 for ; Fri, 18 Jan 2002 11:44:56 -0500 (EST) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0IGiSS21884 for ; Fri, 18 Jan 2002 10:44:28 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g0IGiS229245 for ; Fri, 18 Jan 2002 10:44:28 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id KAA03111 for ; Fri, 18 Jan 2002 10:44:27 -0600 (CST) Reply-To: To: Subject: RE: [Sip] Open Issue #178: Deprecate absolute times absolutely: S PEAK UP IFYOU USE THEM IN YOUR PRODUCT!!!!!!!!!! Date: Fri, 18 Jan 2002 10:44:27 -0600 Message-ID: <61D824C63B99D311975E00508B0CC98502C66D83@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <3C476119.9020604@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > (1) the uas to not be bis-compliant, > (2) expires is needed in INVITE > (3) uas doesn't apply local policy to stop ringing after some > time (very > unlikely, I think) > (4) there is a network outage. > > The odds of simultaneous occurence of all of these four seem > very low to me. > You missed a fifth condition that must also be present: (5) "ICMP address unreachable" packets are discarded by the UAS or other node on the path. Extremely unlikely, indeed. /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 daemon@optimus.ietf.org Fri Jan 18 12:31:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19868 for ; Fri, 18 Jan 2002 12:31:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25717 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 12:31:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22319; Fri, 18 Jan 2002 11:54:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22195 for ; Fri, 18 Jan 2002 11:53:57 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18515 for ; Fri, 18 Jan 2002 11:53:53 -0500 (EST) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id g0IGqoM07887; Fri, 18 Jan 2002 10:52:50 -0600 Message-ID: <005501c1a040$602086a0$0a64a8c0@flak> From: "Dean Willis" To: "Henning G. Schulzrinne" , "Juha Heinanen" Cc: "Jonathan Rosenberg" , References: <3C34C2AD.3000301@dynamicsoft.com> <3C4751B1.8040208@dynamicsoft.com> <15431.48926.519889.351332@harjus.eng.song.fi> <00ca01c1a02a$0e3d1800$0a64a8c0@flak> <15432.11981.90292.43613@harjus.eng.song.fi> <3C48383D.5B26A3C3@cs.columbia.edu> Subject: Re: [Sip] Open Issue #366: sip v. tel URL Date: Fri, 18 Jan 2002 10:51:26 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit No, because quite probably if you're visiting someone else's corporate SIP phone, the gateway that will (perhaps MUST) be used for PSTN termination is the local gateway, not the one back in your home domain. -- Dean ----- Original Message ----- From: "Henning G. Schulzrinne" To: "Juha Heinanen" Cc: "Dean Willis" ; "Jonathan Rosenberg" ; Sent: Friday, January 18, 2002 8:59 AM Subject: Re: [Sip] Open Issue #366: sip v. tel URL > Juha Heinanen wrote: > > > > Dean Willis writes: > > > > > Why shouldn't the default domain to added by a SIP phone be a piece of local > > > configuration information, just as it is for mail and DNS? > > > > because i can log in to a anybodies sip "phone" sitting in some ip > > subnet with whatever sip url i hapens to have. > > > > To make my proposal more concrete: If I log in as foo@example.com, my > home domain is example.com and this home domain will be used for > registrations and default domain for E.164 numbers (and maybe for > preloaded routes, if that matters). Does that work? > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 12:35:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20097 for ; Fri, 18 Jan 2002 12:35:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25980 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 12:35:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24331; Fri, 18 Jan 2002 12:06:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24299 for ; Fri, 18 Jan 2002 12:06:00 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19011 for ; Fri, 18 Jan 2002 12:05:56 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0IH5sio027972; Fri, 18 Jan 2002 19:05:54 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15432.22002.650394.446545@harjus.eng.song.fi> Date: Fri, 18 Jan 2002 19:05:54 +0200 To: "Dean Willis" Cc: "Henning G. Schulzrinne" , "Jonathan Rosenberg" , Subject: Re: [Sip] Open Issue #366: sip v. tel URL In-Reply-To: <005501c1a040$602086a0$0a64a8c0@flak> References: <3C34C2AD.3000301@dynamicsoft.com> <3C4751B1.8040208@dynamicsoft.com> <15431.48926.519889.351332@harjus.eng.song.fi> <00ca01c1a02a$0e3d1800$0a64a8c0@flak> <15432.11981.90292.43613@harjus.eng.song.fi> <3C48383D.5B26A3C3@cs.columbia.edu> <005501c1a040$602086a0$0a64a8c0@flak> X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > No, because quite probably if you're visiting someone else's corporate SIP > phone, the gateway that will (perhaps MUST) be used for PSTN termination is > the local gateway, not the one back in your home domain. that is not true at all. i have a linux sip ua which, when i start it, asks as whom i want to identify myself (my sip from url). i can choose from a list or create a new one. with each identity is associated its own username/password and a sip proxy, which will be used when i register or place a call using that identify. the domain name of the host nor a local gateway has nothing to do with any of this. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 12:36:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20118 for ; Fri, 18 Jan 2002 12:36:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26031 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 12:36:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22546; Fri, 18 Jan 2002 11:59:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22516 for ; Fri, 18 Jan 2002 11:59:06 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18703 for ; Fri, 18 Jan 2002 11:59:02 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA22939; Fri, 18 Jan 2002 11:55:14 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0IGtDJ1003965; Fri, 18 Jan 2002 11:55:13 -0500 (EST) Message-ID: <3C485371.4E2893A6@cs.columbia.edu> Date: Fri, 18 Jan 2002 11:55:13 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: Juha Heinanen , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C34C2AD.3000301@dynamicsoft.com> <3C4751B1.8040208@dynamicsoft.com> <15431.48926.519889.351332@harjus.eng.song.fi> <00ca01c1a02a$0e3d1800$0a64a8c0@flak> <15432.11981.90292.43613@harjus.eng.song.fi> <3C48383D.5B26A3C3@cs.columbia.edu> <005501c1a040$602086a0$0a64a8c0@flak> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > No, because quite probably if you're visiting someone else's corporate SIP > phone, the gateway that will (perhaps MUST) be used for PSTN termination is > the local gateway, not the one back in your home domain. Why is that? In most cases, I would certainly prefer to use my own phone service, rather than the hotel phone service, for example. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 12:56:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20976 for ; Fri, 18 Jan 2002 12:56:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA26436 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 12:56:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24793; Fri, 18 Jan 2002 12:17:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24762 for ; Fri, 18 Jan 2002 12:17:44 -0500 (EST) Received: from imo-r08.mx.aol.com (imo-r08.mx.aol.com [152.163.225.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19419 for ; Fri, 18 Jan 2002 12:17:39 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r08.mx.aol.com (mail_out_v31_r1.25.) id r.21.178c1339 (30974); Fri, 18 Jan 2002 12:17:01 -0500 (EST) Message-ID: <21.178c1339.2979b28c@aol.com> Date: Fri, 18 Jan 2002 12:17:00 EST Subject: Re: [Sip] Issues with telephone-subscriber appearing in a SIP URI. To: rsparks@dynamicsoft.com, sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In a message dated 1/18/02 11:15:06 AM Eastern Standard Time, rsparks@dynamicsoft.com writes: > These tel URIs are equivalent: > tel:+122;parm1=val1;parm2=val2 > tel:+122;parm1=VAL1;PARM2=val2 > tel:+122;parm2=val2;parm1=val1 > There seems to continue to be confusion about the tel: url and its possible forms and uses. I still believe that there needs to be some specific rules. One of those should be that the "+" symbol, as the first character after "tel:" always means that it is following by a complete E.164 number, and never anything else. That means that the above examples are incorrect. +122 is not a legitimate E.164 number. If the above is intended to reflect a legitimate example of something else where the tel: url contains only part of the E.164 number, then a real example should be used. "122" would never make sense because it includes only the first two digits of the three digit area code in the North American Numbering plan. There is no imaginable case in which this would be done. Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 13:07:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21431 for ; Fri, 18 Jan 2002 13:07:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA27172 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 13:07:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25236; Fri, 18 Jan 2002 12:29:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25173 for ; Fri, 18 Jan 2002 12:29:39 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19801; Fri, 18 Jan 2002 12:29:30 -0500 (EST) From: Tom_Gray@Mitel.COM Received: from kanmta01.software.mitel.com (kanmta01.kanata.mitel.com [134.199.37.58]) by Mitel.COM (V8/MAIL-RELAY-2.1) with SMTP id MAA25972; Fri, 18 Jan 2002 12:28:07 -0500 (EST) Received: by kanmta01.software.mitel.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256B45.005FEE8A ; Fri, 18 Jan 2002 12:27:49 -0500 X-Lotus-FromDomain: MITEL To: infovaan@lycos.com cc: infovaan@lycos.com, "SIP List" , "SIP" , "SIP-NG" Message-ID: <85256B45.005FEC6F.00@kanmta01.software.mitel.com> Date: Fri, 18 Jan 2002 12:27:50 -0500 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Sip] Re: [Sipping] how do we handle 911 call originated by SIP user? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org From: Tom Gray@MITEL on 01/18/2002 12:27 PM "Info Van" on 01/18/2002 11:03:06 AM Please respond to infovaan@lycos.com To: infovaan@lycos.com, "Henning G. Schulzrinne" cc: "SIP Implementors Group" , "SIP List" , "SIP" , "SIP-NG" (bcc: Tom Gray/Kan/Mitel) Subject: Re: [Sipping] how do we handle 911 call originated by SIP user? great. where (if any) discussions on this are taking place ? one thing though... whatever infrastructure we have in future, (i am not sure what all is being considered), but we'd still be stuck with "legacy" SIP UA's... which might be difficult to upgrade (or too costly to upgrade with newer technology)...!! so i was thinking, isn't it better to make the solution free (or separate) from infrastructure (s.a. GPS for e.g.). how about a simple solution s.a. (i know it's implementation and it's requirement would be something, not in line with IEFT work, maybe). a user logging-in to a UA (before originating a SIP call), needs to supply (or select from a list, or say "YES" to an option to pick) a postal address (or geographic location), which says is stored by UA, (until it's revoked or expired) and conveyed in an INVITE in a MANDATORY header ?? say sometime like GeoLocation: or something !!! thanks, banibrata dutta. --- On Fri, 18 Jan 2002 10:30:19 Henning G. Schulzrinne wrote: >A new draft on this is in progress. I think there will be several stages >of solutions, depending on what kind of external infrastructure is >available or might be available in the future. I don't know if this is >an official work item of the SIPPING group yet. >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 18 14:14:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23949 for ; Fri, 18 Jan 2002 14:14:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA00154 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 14:14:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27775; Fri, 18 Jan 2002 13:23:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27747 for ; Fri, 18 Jan 2002 13:23:51 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22149 for ; Fri, 18 Jan 2002 13:23:48 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0IILKkN004970; Fri, 18 Jan 2002 13:21:20 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 13:23:09 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9AB@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Mpierce1@aol.com'" , Robert Sparks , sip@ietf.org Subject: RE: [Sip] Issues with telephone-subscriber appearing in a SIP URI . Date: Fri, 18 Jan 2002 13:23:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The number was chosen tersely, to focus the discussion on the comparison issue. (That's also why I didn't use one of the already defined concrete extension headers). Sorry that I set off your "does not parse" flag unnecessarily. RjS > -----Original Message----- > From: Mpierce1@aol.com [mailto:Mpierce1@aol.com] > Sent: Friday, January 18, 2002 11:17 AM > To: rsparks@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] Issues with telephone-subscriber appearing in a SIP > URI. > > > In a message dated 1/18/02 11:15:06 AM Eastern Standard Time, > rsparks@dynamicsoft.com writes: > > > These tel URIs are equivalent: > > tel:+122;parm1=val1;parm2=val2 > > tel:+122;parm1=VAL1;PARM2=val2 > > tel:+122;parm2=val2;parm1=val1 > > > There seems to continue to be confusion about the tel: url > and its possible > forms and uses. I still believe that there needs to be some > specific rules. > One of those should be that the "+" symbol, as the first > character after > "tel:" always means that it is following by a complete E.164 > number, and > never anything else. That means that the above examples are > incorrect. +122 > is not a legitimate E.164 number. If the above is intended to > reflect a > legitimate example of something else where the tel: url > contains only part of > the E.164 number, then a real example should be used. "122" > would never make > sense because it includes only the first two digits of the > three digit area > code in the North American Numbering plan. There is no > imaginable case in > which this would be done. > > Mike Pierce > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 18 15:30:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25991 for ; Fri, 18 Jan 2002 15:30:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03384 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 15:30:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00914; Fri, 18 Jan 2002 14:31:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA00886 for ; Fri, 18 Jan 2002 14:31:17 -0500 (EST) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24289 for ; Fri, 18 Jan 2002 14:31:08 -0500 (EST) Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id TAA21468 for ; Fri, 18 Jan 2002 19:31:05 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002011811331305436 for ; Fri, 18 Jan 2002 11:33:13 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 11:31:05 -0800 Message-ID: From: "Padhye, Chinmay" To: "'sip@ietf.org'" Date: Fri, 18 Jan 2002 11:31:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] A good search utility to search this lists archives. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, I am looking for a good tool to search the archives of this list. The site - http://www1.ietf.org/mail-archive/working-groups/sip/current/index.html shows emails only 4 - 5 days at a time. Any links to other web sites/tools/methods is appreciated. Regards, Chinmay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 18 15:30:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26012 for ; Fri, 18 Jan 2002 15:30:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA03390 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 15:30:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01466; Fri, 18 Jan 2002 14:52:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01390 for ; Fri, 18 Jan 2002 14:52:00 -0500 (EST) Received: from hotmail.com (oe32.law8.hotmail.com [216.33.240.89]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24919; Fri, 18 Jan 2002 14:51:55 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Jan 2002 11:51:21 -0800 X-Originating-IP: [66.62.46.51] From: "Odyssey" To: Cc: "SIP Implementors Group" , "SIP List" , "SIP" , "SIP-NG" References: <3C483F8B.FB5BDEA9@cs.columbia.edu> Date: Fri, 18 Jan 2002 11:56:29 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 18 Jan 2002 19:51:21.0519 (UTC) FILETIME=[80B873F0:01C1A059] Content-Transfer-Encoding: 7bit Subject: [Sip] Guys, I have a suggestion. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit hi, Why everyone still use some open source codes sip stack, debugging and extending. For example, too many guys waste time on Voivda and Osip. Actually, it is very easy to write your own stack with Java, Java RTP. I have written my own stack fully compatiable with JAIN SIP. It will take you no more than two months. Java JDNI support DNS lookup, Java security package, Java JMF, all support you to write a SIP UA or server in no more than two months. Listen to me! I am trying to help you... Best wishes, Yours truly _____________________________________ SCSA, SCNA, OCP 8/8i DBA, CCNA, SCJP, SCJD _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 18 15:58:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26693 for ; Fri, 18 Jan 2002 15:58:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA04320 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 15:58:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02960; Fri, 18 Jan 2002 15:25:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02896 for ; Fri, 18 Jan 2002 15:25:51 -0500 (EST) Received: from hotmail.com (oe38.law8.hotmail.com [216.33.240.95]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25838; Fri, 18 Jan 2002 15:25:46 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 18 Jan 2002 12:25:18 -0800 X-Originating-IP: [66.62.46.51] From: "Odyssey" To: Cc: "SIP Implementors Group" , "SIP" , "SIP-NG" Date: Fri, 18 Jan 2002 12:27:28 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 18 Jan 2002 20:25:18.0757 (UTC) FILETIME=[3F024D50:01C1A05E] Content-Transfer-Encoding: 7bit Subject: [Sip] Guys, I have a suggestion. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit hi, Why everyone still use some open source codes sip stack, debugging and extending. For example, too many guys waste time on Voivda and Osip. Actually, it is very easy to write your own stack with Java, Java RTP. I have written my own stack fully compatiable with JAIN SIP. It will take you no more than two months. Java JDNI support DNS lookup, Java security package, Java JMF, all support you to write a SIP UA or server in no more than two months. Listen to me! I am trying to help you... Best wishes, Yours truly _____________________________________ SCSA, SCNA, OCP 8/8i DBA, CCNA, SCJP, SCJD _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 18 16:24:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27650 for ; Fri, 18 Jan 2002 16:24:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA05237 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 16:24:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04149; Fri, 18 Jan 2002 15:53:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04119 for ; Fri, 18 Jan 2002 15:53:06 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26515 for ; Fri, 18 Jan 2002 15:53:03 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0IKr4H16112; Fri, 18 Jan 2002 15:53:04 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA22792; Fri, 18 Jan 2002 14:53:00 -0600 (CST) Message-ID: <3C488B33.D85D4EB2@lucent.com> Date: Fri, 18 Jan 2002 14:53:07 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories/Lucent Technologies, Inc X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: rsparks@dynamicsoft.com, christer.holmberg@lmf.ericsson.se, james.yu@neustar.com CC: SIP WG List Subject: [Sip] Issues with telephone-subscriber appearing in a SIP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Robert: Funny you should bring this up; Christer, James, and I were discussing this very issue this afternoon here at the SIP 2002 conference. Anyway, my preference is (2) below; but apparently it has already been discussed while I was not quite paying attention. So I guess I loose. The way we have the tel URL parameters in SIP URIs now does not semantically lend 'parameter' status to them; i.e. while parsing them, they will simply be parsed as strings, not as other-param. If they were do be parsed and stored as other-param, a proxy that became LNP aware would already have parsed and stored them as other-params instead of parsing the userinfo part anew. Robert Sparks wrote: > A SIP URI can contain a rfc2806(tel URL) telephone-subscriber > in the userpart of the URI. Previous discussions have made it > clear that tel-url parameters are placed in the userpart of > their sip counterparts. There has been some discussion in the > past on how this interacts with URI equality. To summarize - > > These tel URIs are equivalent: > tel:+122;parm1=val1;parm2=val2 > tel:+122;parm1=VAL1;PARM2=val2 > tel:+122;parm2=val2;parm1=val1 > > But no two of these SIP URIs are equivalent: > > sip:+122;parm1=val;parm2=val2@somewhere.net;user=phone > sip:+122;parm1=VAL1;PARM2=val2@somewhere.net;user=phone > sip:+122;parm2=val2;parm1=val1@somewhere.net;user=phone > > because the userpart of SIP URIs is compared case-sensitive. > > A few ways of addressing this have been kicked around. To > summarize: > > 1) Mandate that ;user=phone appears if and only if the > userpart of a SIP URI is formed as a telephone-subscriber. > This would, in my opinon, be a very bad thing to do. It > effectively makes parsing tel: URLs mandatory (except for > the "tel:" string) and would force every SIP element to > look for and parse the user parameter before it could even > begin to look at the userpart. There are many SIP elements > that are never going to care, and should be treating the > userpart as an opaque string. > > 2) Move the tel URI parameters off into the SIP URI parameter > space. This has been discussed and refused before on the > SIP lists. Among other things, you get into problems with > collisions in the parameter name space. > > 3) Accept and document the limitation. > This is the approach the group has been leaning towards. > To make things better, I would like to add to this that > we suggest a canonical form for the userpart of a SIP URI > when it is a telephone-subscriber. Specifically, such userparts > SHOULD be formed folded to lower-case, with the parameters > ordered lexically by parameter name. Only elements that create > such URIs need to know how to do this - all other elements can > continue to treat the userpart as a blob. > > Comments? In absence of contrary discussion, I will reflect 3) > in bis-06. > > RjS Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 18 18:17:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00355 for ; Fri, 18 Jan 2002 18:17:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA09244 for sip-archive@odin.ietf.org; Fri, 18 Jan 2002 18:17:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08906; Fri, 18 Jan 2002 18:01:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08875 for ; Fri, 18 Jan 2002 18:01:11 -0500 (EST) Received: from tester.dc90.com ([211.116.140.157]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29994 for ; Fri, 18 Jan 2002 18:01:04 -0500 (EST) Message-Id: <200201182301.SAA29994@ietf.org> Received: (qmail 6201 invoked from network); 18 Jan 2002 15:15:51 -0000 Received: from unknown (HELO pjs) (211.116.140.231) by 211.116.140.157 with SMTP; 18 Jan 2002 15:15:51 -0000 From: DC90 To: sip@ietf.org X-Mailer: Microsoft Outlook Express 5.00.2615.200 Reply-To: pjs7353@lycos.co.kr Date: Sat, 19 Jan 2002 00:15:15 +0900 Mime-Version: 1.0 Content-Type: text/html; charset=ks_c_5601-1987 Subject: [Sip] [±¤°í]BMW 7980¿ø,³ëÆ®ºÏ 2250¿ø, ÇÁ¶ó´Ù ¼ñ´õ¹é 6500¿ø¿¡ À常ÇÏ½Ç ¼ö ÀÖ½À´Ï´Ù Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Á¦¸ñ¾øÀ½

DC90.COM !! ½Å°³³äÀÇ ÀÔÂû½Ä ¼îÇθô


BMW 5½Ã¸®Áî 530i

½ÃÁß°¡: 79,800,000¿ø
ÀÔÂû°¡: 7,980¿ø

ÀÔÂû Âü¿©

 

½Å°³³äÀÇ ÀÔÂû½Ä ¼îÇθôÀÎ dc90.comÀÌ »õ·Ó°Ô ¿ÀÇÂÇß½À´Ï´Ù.

dc90.comÀÇ ÀÔÂû½Ä ¼îÇθôÀº È¥ÀÚ ±¸¸ÅÇϱ⿣ ºÎ´ã½º·´°í ±×·¯³ª ²À °®°í ½Í¾ú´ø »óÇ°À» ¿©·¯¸íÀÌ ºñ¿ëÀ» ³ª´©¾î ºÎ´ãÇÑ ÈÄ, ÇÑ »ç¶÷ÀÇ ³«ÂûÀÚ¿¡°Ô ¸ô¾ÆÁÖ´Â ¹æ½ÄÀÇ ½Å°³³ä ¼îĪ¸ôÀÔ´Ï´Ù.

ÀÔÂû¿¡ Âü¿©ÇÑ ÈÄ, ³«ÂûµÇÁö ¾Ê¾ÒÀ» °æ¿ì´Â ¾î¶»Çϳİí¿ä?
°ÆÁ¤¸¶½Ê½Ã¿ä. dc90.comÀº ¿©·¯ºÐÀÌ ÀÔÂû¿¡ »ç¿ëÇÑ ¼ÒÁßÇÑ ÀÔÂû±ÝÀ» »çÀ̹ö¸Ó´Ï·Î µ¹·Áµå·Á¼­ dc90.com¿¡¼­ ¿î¿µÇÏ´Â ÀϹݼîÇθôÀÇ »óÇ°À» ÀÚÀ¯·ÎÀÌ ±¸¸ÅÇÒ ¼ö ÀÖµµ·Ï ÇÏ¿´½À´Ï´Ù.

 
 
  ÀÔÂû¿¡ Âü¿©Çϸé Âü¿©±Ý¾×ÀÇ 5%¸¦ ÀÔÂû¿¹Ä¡±ÝÀ¸·Î ¿¹Ä¡ÇØ Áشٰí!!!
2002³â 1¿ù 31ÀϱîÁö ÀÔÂû¿¡ Âü¿©ÇϽô ºÐ Áß ¼±Âø¼ø
1,000ºÐ±îÁö ÀÔÂû¿¡ Âü¿©ÇÑ Âü¿©±Ý¾×ÀÇ 5%¸¦ ÀÔÂû¿¹Ä¡±ÝÀ¸·Î ¿¹Ä¡ÇØ µå¸³´Ï´Ù.
(´Ü, ÀÔÂûÀÌ Ãë¼ÒµÇ¾î ÀÔÂû¿¹Ä¡±ÝÀ¸·Î ȯºÒÇÑ °æ¿ì´Â Á¦¿Ü ÇÕ´Ï´Ù.)
 
 
 

ÀÔÂû¿¡ Âü¿©ÇÏ¸é °æÇ°ÀÌ ½ñ¾ÆÁø´Ù!!!
2002³â 1¿ù 31ÀϱîÁö ÀÔÂû¿¡ ÇѹøÀÌ»ó Âü¿©ÇϽŠȸ¿øºÐ Áß ³«Âû¹ÞÁö
¸øÇϽŠȸ¿ø´Ôµé²²´Â Ãß÷À» ÅëÇØ ÇªÁüÇÑ °æÇ°À» µå¸³´Ï´Ù.
(´Ü, ÇØ´ç »óÇ°ÀÇ ÀÔÂûÀÌ Ãë¼ÒµÈ °æ¿ì´Â Á¦¿Ü ÇÕ´Ï´Ù.)

1µî 1¸í : ³ëÆ®ºÏ[ÈÄÁöÂê][PIII 1GHz] C-7631DV
2µî 2¸í : »ï¼º Syncmaster LCD 175MP
3µî 3¸í : OLYMPUS Mu Zoom 140 QD CG
4µî 4¸í : ÀÔÂû¿¹Ä¡±Ý 20¸¸¿ø
5µî 5¸í : ÀÔÂû¿¹Ä¡±Ý 10¸¸¿ø

 
 
  ¼ö¼ö·á°¡ ¸éÁ¦µË´Ï´Ù!!!!
2002³â 1¿ù 31ÀϱîÁö ÀÔÂû¿¡ Âü¿©ÇϽô ºÐ²²´Â ¼ö¼ö·á¸¦ °øÁ¦ÇÏÁö ¾ÊÀº
ÀÔÂûÂü¿©±Ý Àü¾×À» »çÀ̹öij½¬·Î Àû¸³ÇÏ¿© µå¸³´Ï´Ù.
Copyright ¨Ï 1998-2001 by DC90. All rights reserved

 

´ÙÀ½ºÎÅÍ È«º¸¸ÞÀÏÀ» ¹ÞÁö ¾ÊÀ¸½Ã·Á¸é ¿©±â¸¦ ´­·¯ÁÖ¼¼¿ä.

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 20 15:19:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15578 for ; Sun, 20 Jan 2002 15:19:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26167 for sip-archive@odin.ietf.org; Sun, 20 Jan 2002 15:19:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25491; Sun, 20 Jan 2002 14:56:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25460 for ; Sun, 20 Jan 2002 14:56:11 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15307 for ; Sun, 20 Jan 2002 14:56:06 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0KJtkw24076; Sun, 20 Jan 2002 20:55:47 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0KJtjr6020326; Sun, 20 Jan 2002 21:55:45 +0200 (EET) Message-ID: <3C4B20E5.AF3CA615@lmf.ericsson.se> Date: Sun, 20 Jan 2002 21:56:21 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: rsparks@dynamicsoft.com, james.yu@neustar.com, SIP WG List Subject: Re: [Sip] Issues with telephone-subscriber appearing in a SIP References: <3C488B33.D85D4EB2@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, First, I must also admit that I haven't followed the discussion, and wasn't aware about the issue until Paris. Like Vijay, I would vote for (2). However, I strongly dissagree that the parameters should be allowed in the user part, unless they are treated like parameters. By saying that servers which don't understand the parameters should just treat the whole user part as a string will cause problems. For example, assume that a PSTN gateway is able to route the number "12345" to the PSTN network. Now, if it receives sip:12345;parm1=XXX@myGateway.com, and it treats the user part as a string, it would try to route "12345;parm1=XXX" to the PSTN network, and that would obviously not work. If it would be able to separate "parm1=XXX" as parameters, however, it would be able to route "12345" to the PSTN network - no matter if it understands the parm1 parameter or not. So, my opinion is that if we don't define parameters in the ABNF they shall NOT be there. So, assuming we want to be able to have the parameters in the user part, the options I can come up with are: 1. We specify that user=phone means the server MUST treat the SIP-URI user part as a TEL-URL (this is the same as proposal (1)). 2. We define a Require header option-tag, which requires the server to treat the SIP-URI user part as a TEL-URL. Regards, Christer Holmberg Ericsson Finland "Vijay K. Gurbani" wrote: > > Robert: > > Funny you should bring this up; Christer, James, and I were discussing this > very issue this afternoon here at the SIP 2002 conference. > > Anyway, my preference is (2) below; but apparently it has already been > discussed while I was not quite paying attention. So I guess I loose. > > The way we have the tel URL parameters in SIP URIs now does not semantically > lend 'parameter' status to them; i.e. while parsing them, they will simply > be parsed as strings, not as other-param. If they were do be parsed > and stored as other-param, a proxy that became LNP aware would > already have parsed and stored them as other-params instead of parsing > the userinfo part anew. > > Robert Sparks wrote: > > A SIP URI can contain a rfc2806(tel URL) telephone-subscriber > > in the userpart of the URI. Previous discussions have made it > > clear that tel-url parameters are placed in the userpart of > > their sip counterparts. There has been some discussion in the > > past on how this interacts with URI equality. To summarize - > > > > These tel URIs are equivalent: > > tel:+122;parm1=val1;parm2=val2 > > tel:+122;parm1=VAL1;PARM2=val2 > > tel:+122;parm2=val2;parm1=val1 > > > > But no two of these SIP URIs are equivalent: > > > > sip:+122;parm1=val;parm2=val2@somewhere.net;user=phone > > sip:+122;parm1=VAL1;PARM2=val2@somewhere.net;user=phone > > sip:+122;parm2=val2;parm1=val1@somewhere.net;user=phone > > > > because the userpart of SIP URIs is compared case-sensitive. > > > > A few ways of addressing this have been kicked around. To > > summarize: > > > > 1) Mandate that ;user=phone appears if and only if the > > userpart of a SIP URI is formed as a telephone-subscriber. > > This would, in my opinon, be a very bad thing to do. It > > effectively makes parsing tel: URLs mandatory (except for > > the "tel:" string) and would force every SIP element to > > look for and parse the user parameter before it could even > > begin to look at the userpart. There are many SIP elements > > that are never going to care, and should be treating the > > userpart as an opaque string. > > > > 2) Move the tel URI parameters off into the SIP URI parameter > > space. This has been discussed and refused before on the > > SIP lists. Among other things, you get into problems with > > collisions in the parameter name space. > > > > 3) Accept and document the limitation. > > This is the approach the group has been leaning towards. > > To make things better, I would like to add to this that > > we suggest a canonical form for the userpart of a SIP URI > > when it is a telephone-subscriber. Specifically, such userparts > > SHOULD be formed folded to lower-case, with the parameters > > ordered lexically by parameter name. Only elements that create > > such URIs need to know how to do this - all other elements can > > continue to treat the userpart as a blob. > > > > Comments? In absence of contrary discussion, I will reflect 3) > > in bis-06. > > > > RjS > > Regards, > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Internet Software and eServices Group > Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 02:15:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01885 for ; Mon, 21 Jan 2002 02:15:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA23197 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 02:15:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22488; Mon, 21 Jan 2002 01:51:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22461 for ; Mon, 21 Jan 2002 01:51:03 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23470 for ; Mon, 21 Jan 2002 01:51:00 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0L6p1w14418 for ; Mon, 21 Jan 2002 07:51:01 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.3]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0L6p0r6016558 for ; Mon, 21 Jan 2002 08:51:01 +0200 (EET) Message-ID: <3C4BBA80.2C29337C@lmf.ericsson.se> Date: Mon, 21 Jan 2002 08:51:44 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Comments on "unify" draft - Part II Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Here are some comments on unify. To make all issue easier to follow, I will continue the numbering from where Rohan ended. Chapter 5.1 describes how the One-of-N codec negotiation takes place. My questions related to this: 7) If the same method, using two INVITEs, is used also for re-INVITEs in the middle of the call (I assume it must be used also if the re-INVITE contains a set of codecs and we need to pick one), how does it affect the rule that "there must be no media cut while the codec re-negoatiation takes place"? We do set the mode to "inactive" in the first INVITE, so it would affect the media... Chapter 5.4 describes how the early media takes place. My question(s) related to this: 8) How does the UAC know there will be early media, so it sets the mode to "sendrecv", when 5.1 says it shall set the mode to "inactive" for the first INVITE? 9) Since 5.1 describes how the media negoatiation is done using two INVITEs, how does the UAS suddenly know which codec to use (for the early media) after receving only one INVITE? I think the One-of-N codec problem affects also the early media, doesn't it? 10) IF the COMET (Rohan had some issues about that) is used to refuse early media, why can't it also be used to accept early media - and include the "final" codec for the early media? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 08:51:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09644 for ; Mon, 21 Jan 2002 08:51:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA07747 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 08:51:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06016; Mon, 21 Jan 2002 08:14:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05982 for ; Mon, 21 Jan 2002 08:14:22 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08219 for ; Mon, 21 Jan 2002 08:14:18 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0LDDnv28121 for ; Mon, 21 Jan 2002 08:13:50 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Jan 2002 13:13:48 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0042470C5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: sip@ietf.org Date: Mon, 21 Jan 2002 13:13:45 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [Sip] bis-draft: minor issues in Table 2 and 3 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Issue 1: I note that o in the main part of these tables means according to the following text appearing before the table: "Optional" means thata UA MAY include the header field in a request or response, and a UA MAY ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 22.30). A "mandatory" header field MUST be present in a request, and MUST be understood by the UAS receiving the request. A mandatory response header field MUST be present in the response, and the header field MUST be understood by the UAC processing the response. "Not applicable" means for header fields that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the UAS receiving the request. Similarly, a header field labeled "not applicable" for a response means that the UAS MUST NOT place the header in the response, and the UAC MUST ignore the header in the response. Optional to send and optional to receive. The text makes one exception in the Require header. There are other headers where the bis draft specifies that an action is mandatory on receipt of a particular header. Examples: 8.2.4 specifies: If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content-Disposition) header, the UAS MUST reject the request with a 415 (Unsupported Media Type) response. 8.2.5 specifies: A UAS that wishes to apply some extension when generating the response MUST only do so if support for that extension is indicated in the Supported header in the request. and also: Any extensions applied to a non-421 response MUST be listed in a Require header included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header in the request. I am sure that other examples can be found. Issue 2: The Warning header is listed as a response header, but it is stated as "o" for ACK. It should be "-" Issue 3: As indicated in a previous mail, all "g" should be removed from the where column in these tables, as the correct indication of applicability to both a request and a response is a blank entry. This applies to the Require and To headers. Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 10:50:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13215 for ; Mon, 21 Jan 2002 10:50:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA13638 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 10:50:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11549; Mon, 21 Jan 2002 10:11:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11518 for ; Mon, 21 Jan 2002 10:11:47 -0500 (EST) Received: from localhost ([218.55.130.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11814 for ; Mon, 21 Jan 2002 10:11:39 -0500 (EST) Message-Id: <200201211511.KAA11814@ietf.org> Reply-To: naracom2002@naver.com From: Ä£±¸¿¡°Ô To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 22 Jan 2002 00:14:06 +0900 Subject: [Sip] ¾È³çÇϼ¼¿ä[È«º¸] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org ¼±ºÒ¿ä±ÝÁ¦ ÂüÁ¶ÀÚ·áÁý

¾È³çÇϼ¼¿ä ÀúÈ£ÁØÀÌ¿¡¿ä
ÀßÁö³»°í °è½ÃÁ®?
ÁÁÀºÁ¤º¸°¡ ÀÌ·¸°Ô ¸áº¸³» µå·Á¿ä
Çѹø ²Ä²ÄÈ÷ µûÁ®º¸¼¼¿ä ¾Æ¸¶ ¸¹Àºµµ¿òµÉ°Å¿¡¿ä
¾Æ·¡¿¡ ÆÄÀÏ÷ºÎÇßÀ¸´Ï Àо½Ã°í¿ä
±×·³ ¶Ç ¸áµå¸±²²¿ä








¼±ºÒ¿ä±ÝÁ¦¼­ºñ½º´Â ¾î´À³¯ °©Àڱ⠳ª¿Â ¼­ºñ½º°¡ ¾Æ´Ñ, ¼±Áø ¿©·¯³ª¶ó¿¡¼­´Â ÀÌ¹Ì ±âÁ¸¿¡ ½Ç½ÃÇÏ°í´Â ¼­ºñ½º·Î ȸ»çÀÇ ÀÔÀå¿¡¼­´Â ¾ÈÁ¤ÀûÀÌ¸ç ¹Ì³³ °ÆÁ¤ÀÌ ¾ø´Â ȸ¿øÀ¯Ä¡¸¦ ÇÏ¿© ȸ»çÀÇ ¾ÈÁ¤¼ºÀ» ²ÒÇÒ ¼ö ÀÖÀ¸¸ç, ÀÌ¿¡µû¸¥ °í°´Àº °¢Á¾ ÇýÅà ¹× ¼ö´çÀ» ¹Þ´Â °ÍÀÔ´Ï´Ù.
Áï ¼±ºÒÁ¦¿ä±ÝÁ¦¶õ ¸ÕÀú ÀÏÁ¤ºÎºÐÀÇ Åë½Å·á¸¦ ³»°í ij½¬¹é(Çö±Ý)°ú ±âŸ ¼ö´çÀ» ¹Þ´Â ¿ä±Ýü°èÀ̸ç, ÀÌ·ÎÀÎÇÑ ÇýÅÃÀ» °í°´¿¡°Ô Å©°Ô´Â 35%¿¡ ÇØ´çµÇ´Â ºÎºÐÀ» ´Ù½Ã Çö±ÝÀ¸·Î µ¹·Áµå¸®°í ÀÖ½À´Ï´Ù.
 

1. ¾Ç¼º¿¬Ã¼ ¿ä±ÝÀ¸·Î ÀÎÇÑ ±ÝÀ¶ ½Å¿ëºÒ·®ÀÚÀÇ Áõ°¡.
2. ÀÎÀû, ¹°ÀûÀ¸·Î ¸¹Àº °ü¸®ºñ¿ë ÇÊ¿ä (¿ä±Ý°íÁö, ä±Ç°ü¸® µî).
3. À̵¿Åë½Å »ç¿ëÀÚ°¡ »ç¿ë¿ä±ÝÀÇ ÀÎÁö¾øÀÌ ¹«ºÐº°ÇÑ »ç¿ëÀ¸·Î ÀÎÇÑ °ú¼Òºñ ÃÊ·¡.

ÀÌ·¯ÇÑ, ¹®Á¦·Î ÀÎÇØ ¼¼°èÀûÀ¸·Î À̵¿Åë½ÅÀº ¼±ºÒ¿ä±ÝÁ¦·Î ÀüȯµÇ°í ÀÖ½À´Ï´Ù.
¡Ø 2002³â¿¡´Â IMT2000 ¼­ºñ½º°¡ ½ÃÀ۵Ǹç, ±×¶§´Â Áö±Ý »ç¿ë¿ä±ÝÀÇ 3~4¹è¿¡ À̸£´Â ¼­ºñ½º ¿ä±ÝÀÌ »ç¿ëµÉ °ÍÀ̶ó°í ¿¹ÃøÇÏ°í ÀÖ½À´Ï´Ù. Åë½Å½ÃÀåÀÌ °³¹æµÇ¾úÀ½¿¡µµ ºÒ±¸ÇÏ°í, ¿Ü±¹ÀÇ °Å´ëÅë½Å±â¾÷µéÀÌ Áö±Ý ÀáÀáÇÑ°ÍÀº ¹Ù·Î ÀÌ IMT2000 ½Ã´ëÀ» ±â´Ù¸®¸ç, ¿ì¸®³ª¶ó Åë½Å½ÃÀåÀ» ³Ñº¸°í ÀÖ´Â °ÍÀÔ´Ï´Ù.

: °³Àδ븮Á¡À¸·Î ±¸¼º
°íÁ¤µÈ Áö¿ª ´ë¸®Á¡À» Å»ÇÇÇÏ¿© Áö¿ª¿¡ »ó°ü¾øÀÌ ¿òÁ÷ÀÌ´Â ´ë¸®Á¡À¸·Î ±¸¼º
¡¡

ÀϹݴ븮Á¡

KTF ¼±ºÒ´ë¸®Á¡

¹ü        À§

Áö¿ªº° ÇÑ°è Áö¿ª Á¦ÇѾøÀÌ Àü±¹
½Ã        ¼³ ¸ÅÀå ÀÓ´ë (º¸Áõ±Ý + ½Ã¼³ºñ µî) ¸ÅÀå ºÒÇÊ¿ä
´ã        º¸ ´Ü¸»±â ±¸¸Å¸¦ À§ÇØ ´ãº¸¹° Á¦°ø ´ãº¸ ¾øÀ½
°ü ¸® À¯ Áö °ü¸® Àοø ¹× °ü¸®ºñ °ú´Ù ÁöÃâ ¾øÀ½
¼ö   ¼ö   ·á °ü¸®¼ö¼ö·á ȸ¿øÀå·Á±Ý
½Ã   Àå   ¼º ½ÃÀ强ÀÌ ¾ø´Ù. (Æ÷È­»óÅÂ) ¹«ÇÑÇÑ ½ÃÀ强 (Ãʱâ½ÃÀå ¼±Á¡)
ÇØ   Áö   À² °í°´ À̵¿ÀÌ ¸¹´Ù.

(´ë¸®Á¡°£ °ø¿ë½Ã½ºÅÛ)		 °í°´À̵¿ ¾øÀ½.

(Àü¿ë½Ã½ºÅÛ)
     

 ¢º »ç¿ëÀÌ ºÒÆíÇÏ´Ù : Á¢¼Ó¹øÈ£¿Í  Ä«µå¹øÈ£¸¦ ÀÔ·ÂÇÑ ÈÄ »ç¿ëÇÏ¿©¾ß ÅëÈ­°¡ ¿¬°áµË´Ï´Ù.
 ¢º ½Ã¿ÜÀüÈ­ : ±â¾÷, ȸ»ç¿¡¼­ ¸¹ÀÌ »ç¿ë (¾à 2Á¶¿ø)  °³ÀÎÀº 1°¡±¸´ç ¾à 4,600¿ø »ç¿ë
 ¢º ±¹Á¦ÀüÈ­ : ±â¾÷, ¹«¿ªÈ¸»ç, ¿ÀÆÄ»óµîÀÌ ¸¹ÀÌ »ç¿ë (¾à1Á¶¿ø) °³ÀÎ »ç¿ëÀº ¹ÌºñÇÏ´Ù.

     
   ¢º »ç¿ëÀÌ Æí¸®ÇÏ´Ù. : ÈÄºÒ ÀüÈ­ »ç¿ë°ú µ¿ÀÏ
 ¢º 2,750¸¸¸íÀÌ ³Ñ´Â ´ëºÎºÐÀÇ °í°´ÀÌ °³ÀÎÀ¸·Î ±¸¼ºµÇ¾î ÀÖ½À´Ï´Ù.
 ¢º ¼±ºÒ½ÃÀåÀº ¹«ÇÑÇÕ´Ï´Ù. : 2750¸¸ Èĺҿä±Ý »ç¿ë°í°´
 ¢º 1°¡±¸´ç 11¸¸¿ø ÀÌ»ó »ç¿ëÇÕ´Ï´Ù. (1999³â Åë°è)
¿ä±Ý»óÇ° ÀÏ ±âº»·á ¿ù ±âº»·á ±¹³»ÅëÈ­·á 
(¿ø/10ÃÊ)		 ºñ °í
Æò»ó ÇÒÀÎ ½É¾ß
¼±ºÒ Ç¥ÁØ 533 ¿ø 16,000 ¿ø 18 ¿ø 15 ¿ø 10 ¿ø ¡¡
¼±ºÒ ¿¡À̽º 616 ¿ø 18,500 ¿ø 15 ¿ø 14 ¿ø 13 ¿ø ¡¡
¼±ºÒÇÁ¸® 200 1,183 ¿ø 35,500 ¿ø 17 ¿ø 14 ¿ø 10 ¿ø 200ºÐ ¹«·á

  ¢º ¿ä±Ý»óÇ° º¯°æ½Ã Àû¿ë½ÃÁ¡ : º¯°æ°ú µ¿½Ã¿¡ º¯°æ¿ä±ÝÀ¸·Î Á¤»êµÇ³ª, ¿ù 1ȸ¿¡ ÇÑÇÔ.
  ¢º ÇÒ ÀÎ ½Ã °£
    1) ¼±ºÒÇ¥ÁØ, ¼±ºÒ¿¡À̽º ¿ä±ÝÀÇ °æ¿ì
       - ÆòÀÏ (Åä¿äÀÏ Æ÷ÇÔ) : 0 ~ 6 ½Ã (½É¾ß) / 6 ~ 12 (ÇÒÀÎ) / 12 ~ 24 (Æò»ó)     
       - °øÈÞÀÏ (ÀÏ¿äÀÏ Æ÷ÇÔ) : 0 ~ 6½Ã (½É¾ß) / 6 ~ 24 (ÇÒÀÎ)
     2) ¼±ºÒÇÁ¸® 200 ¿ä±ÝÀÇ °æ¿ì
       - ÆòÀÏ (Åä¿äÀÏ Æ÷ÇÔ) : 0 ~ 6 ½Ã (½É¾ß) / 6 ~ 8, 21 ~ 24 (ÇÒÀÎ) / 8 ~ 21 (Æò»ó)
       - °øÈÞÀÏ (ÀÏ¿äÀÏ Æ÷ÇÔ) : 0 ~ 6½Ã (½É¾ß) / 6 ~ 24 (ÇÒÀÎ)


 KTF(Çѱ¹Åë½ÅÇÁ¸®ÅÚ)ÀÇ Åº»ý ´ç½ÃºÎÅÍ ¸ðµç ½Ã½ºÅÛÀ» ´ã´çÇØ ¿Â  ´ë¿ìÁ¤º¸½Ã½ºÅÛÀº 
 ±âÁ¸ ÀüÀÚ»ó°Å·¡ÀÇ ±â¹ÝºÎÀç·Î ¿À´Â ÀûÀÚ¿äÀÎÀ» ÁÖ½Äȸ»ç ³ª¶óÄÞÀÇ ³×Æ®¿öÅ© ¸¶ÄÉÆÃÀ»  
 ÅëÇÏ¿© ÃִܱⰣ ÃÖ´ëȸ¿øÀÇ ±â¹ÝÈ®º¸¸¦ ¸ñÇ¥·Î  KTF, ´ë¿ìÁ¤º¸½Ã½ºÅÛ, ÁÖ½Äȸ»ç
 ³ª¶óÄÞÀÇ Àü·«Àû Á¦ÈÞ¸¦ ÅëÇÏ¿© 
 ¼±Áø±¹Çü ¼±ºÒ¿ä±ÝÁ¦µµ
- KTF 016 ¼±ºÒ¿ä±ÝÁ¦µµ -
¸¦  ź»ý½ÃÄ×½À´Ï´Ù.

E-mail : corud2@dreamwiz.com
  
±ÍÇÏÀÇ E-MAILÀº °ü·Ã °Ô½ÃÆÇÀ» ÅëÇØ ¾Ë°Ô µÇ¾ú½À´Ï´Ù.
¿øÄ¡ ¾Ê¾Ò´ø ¸ÞÀÏÀ̶ó¸é ¿©±â¸¦ ´­·¯ ¾Ë·Á ÁÖ½Ã¸é ¾ÕÀ¸·Î´Â ¹ß¼ÛµÇÁö ¾Êµµ·Ï ÇÏ°Ú½À´Ï´Ù.

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 11:20:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14939 for ; Mon, 21 Jan 2002 11:20:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15677 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 11:20:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13847; Mon, 21 Jan 2002 10:53:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13816 for ; Mon, 21 Jan 2002 10:53:06 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13296 for ; Mon, 21 Jan 2002 10:53:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0LFrAGe025106; Mon, 21 Jan 2002 10:53:10 -0500 (EST) Message-ID: <3C4C393F.6080400@dynamicsoft.com> Date: Mon, 21 Jan 2002 10:52:31 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: "unify" draft: problem with upstream 407 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > Hi, > > I noticed another issue with the proposed HERFP solution in the unify > draft with respect to upstream 407s. > > suppose UA A sends to Proxy 1 which forks to b@domain1 and c@domain2 > > to get to c@domain2 the request is routed through a non-forking proxy > (Proxy 2) which sends a 407. How is this response handled? Yeah, this case isn't well covered by the proposal. I will note that I think this case is highly unlikely. Generally, the proxies that challenge are the ones that have a relationship with the caller. Calls fork generally because the called party has multiple locations, and therefore, the forking is in the domain of the called party. I cannot think of a real example where a 407 would actually come after a call was forked to reach the called party. > > - it doesn't seem that proxy 2 could send a 155 since it probably isn't > capable of receiving a COMET and forwarding an INVITE (breaks > idempotency) > > - proxy 2 could send a 407, which proxy 1 packages in a 155, UA A sends > a > COMET, proxy 1 sends a new INVITE (same CSeq new branch)... This might work. I had actually thought of that for the UA case as well, to handle the scenario where the UAS doesn't support 155. Not sure its really a case we need to worry about though, as above. > Looking carefully at the status codes, the proposed HERFP solution works > perfectly with 1xx, 2xx, and 6xx responses because it doesn't change any > behavior there. It works fine with 3xx if recursion is turned on. It > works fine for 5xx with the possible exception of 513 (presumably you > could strip some crud and try to send a smaller message, but that is not > a great loss). The 4xx responses seem to fall into 3 categories: > > 1) there is no recourse if the branch fails, so retrying is irrelevant: > 400, 403, 404, 408, 410, 414, 421, 481, 482, 483, 486, 487, 405?, 406?, > 480? I think 421 might work for HERFP, you can resubmit with Supported. 406 might work as well with HERFP. I don't think 480 would work. > > 2) if the branch fails, you could use a 155 and expect recourse with a > COMET: 401, 402, 488, and possibly 415? Yes, 415 and 420 too. 415 was one of the original motivators for this problem. We'll need it for the transition from SDP to SDPng. Lets say a UAC sends an INVITE with SDPng, and that forks to two UAS, one that supports it, and the other, that doesnt. This is a case of HERFP where 415 will be sent. > > 3) if the branch fails it is unlikely that you can fix the problem with > a > COMET, but you could (at least theoretically) fix the problem with a new > INVITE: 407, 420, 484 (no great loss when forking), 485, and 413? I think 420 could be fixed with a COMET; the processing would effectively proceed as if it was the COMET that were the INVITE. Things that otherwise will change the destination, like 485 and 413, cannot be fixed with COMET. 484 is the same. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 11:27:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15515 for ; Mon, 21 Jan 2002 11:27:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15844 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 11:27:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14823; Mon, 21 Jan 2002 11:03:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14719 for ; Mon, 21 Jan 2002 11:03:49 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13869 for ; Mon, 21 Jan 2002 11:03:45 -0500 (EST) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id g0LG3lM22571; Mon, 21 Jan 2002 10:03:47 -0600 Message-ID: <000201c1a294$f6fd4ee0$8a036e3f@flak> From: "Dean Willis" To: Cc: References: <17052388D394D411803900508BDFFAF601B37166@n0214idc1.oss.level3.com> Subject: Re: [Sip] Attention - comment on Loose Routing draft Date: Sun, 20 Jan 2002 12:01:33 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'll give an example that describes the problem I think you're seeing -- I'm probably understanding you wrong, so flame on . . . Ok, let's say we have established a dialog routed UA1, P1, P2, UA2. P2 has resources tied up. After some time, P1 decides to "retarget" the dialog by altering the destination of a reINVITE issued by P1. P1 rewrites the request-URI and/or routes such that the reinvite traverses P3 and arrives at UA3. Yes, this is bad, as it leaves P2 holding resources. But it's bogus more ways than that . . . But what if P1 has knowledge that P2 has failed, and it re-routes thru P3 in order to get to UA2, the original target? -- Dean ----- Original Message ----- From: To: Cc: ; ; Sent: Friday, January 18, 2002 9:20 AM Subject: RE: [Sip] Attention - comment on Loose Routing draft > > The UAC considers it a re-Invite even when a proxy later re-writes the > r-uri (a common action). I'm not clear where you are headed with this line > of thought wrt Robert's draft. > > John Hearty > Level3 > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, January 18, 2002 7:06 AM > To: Hearty, John > Cc: rsparks@dynamicsoft.com; bernhard.honeisen@nokia.com; sip@ietf.org > Subject: Re: [Sip] Attention - comment on Loose Routing draft > > > Changing the request-URI in a reinvite makes it not a reinvite, right? > > -- > Dean > > ----- Original Message ----- > From: > To: > Cc: ; ; > Sent: Thursday, January 17, 2002 9:22 AM > Subject: RE: [Sip] Attention - comment on Loose Routing draft > > > > > > I would have to disagree with you too. This sounds like trouble brewing, > > especially in transactions subsequent to the first. Take for example a > > firewall control proxy downstream from X. An initial Invite sets up > > firewall resources. If a re-Invite comes through and X decides service > > route points downstream from X don't matter anymore, you just stranded > > firewall resources. > > > > John Hearty > > Level3 > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Thursday, January 17, 2002 3:55 AM > > To: Honeisen Bernhard (NET/Helsinki); sip@ietf.org > > Cc: 'ext Robert Sparks' > > Subject: Re: [Sip] Attention - comment on Loose Routing draft > > > > > > Hmm, RjS may disagree, but I think that the retargeting of the message at > X > > might override the service routing in the original request. Changing the > > request URI means to me "don't send it to where it was being sent, send it > > to this other place instead". Given this logic, service route points > > downstream from X probably don't matter anymore. > > > > -- > > Dean > > > > ----- Original Message ----- > > From: "Honeisen Bernhard (NET/Helsinki)" > > To: > > Cc: "'ext Robert Sparks'" > > Sent: Tuesday, January 15, 2002 9:05 AM > > Subject: RE: [Sip] Attention - comment on Loose Routing draft > > > > > > > Hi RjS! > > > > > > Some question: > > > > > > Consider a situation, where a request is directed > > > to (B) and two service elements (X) and (Y) have > > > to be visited before. > > > (X) performs a service, which replaces the intended > > > destination URL, i.e. (B), whereas (Y) executes > > > some feature, which depends on the output of (X). > > > > > > When the request arrives at (X), the R-URI / Route > > > could look like: > > > - R-URI: > > > - Route: , > > > (The intended destination has been appended earlier > > > to Route as per section 5.2 in your I/D) > > > > > > How can (X) now apply the destination URL relacing feature? > > > My first guess was, that (X) would modify the last entry > > > in the Route, i.e. (B). > > > > > > Your first proposal in section 2 prohibits such behavior: > > > "[...] an element [...] MUST NOT modify or remove > > > subsequent Route header field values." > > > > > > Is this restriction intended also for such cases or could > > > we relax it to allow modifying of the last entry in Route? > > > Would marking the last Route entry as the intended > > > destination (and allow modifying of such only) solve > > > this issue? > > > > > > Greetings, > > > Bernie > > > > > > > > > PS: Some Typos: > > > > > > - section 5.5, F7-F12: > > > s/Contact: sip:jbj@212.28.214.227/Contact: sip:jbj@212.28.214.228/ > > > > > > - section 5.5. F3/F4: > > > - Shouldn't maddr in F4 contain a different IP-address > > > than in F3? > > > - Maybe add a FQDN <-> IP mapping table to ease > > > the understanding of the examples. > > > > > > - section 5.8: > > > s/senting/sending/ > > > > > > > > > > > > >-----Original Message----- > > > >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > >Sent: 14. January 2002 20:58 > > > >To: 'sip@ietf.org' > > > >Subject: [Sip] Attention - comment on Loose Routing draft > > > > > > > > > > > >The draft below contains the resolution to a large > > > >set of open issues around processing of the Route header, > > > >preloaded routes, and the use of default outbound proxies. > > > >The plan is to modify bis to reflect these proposals. > > > > > > > >Please review it as soon as you can and comment if you > > > >see real problems. Silence will be taken as consent. > > > > > > > >RjS > > > > > > > >> -----Original Message----- > > > >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > >> Sent: Thursday, January 10, 2002 10:46 PM > > > >> To: 'sip@ietf.org' > > > >> Subject: [Sip] Loose Routing draft > > > >> > > > >> > > > >> I just submitted a draft refining the post I sent > > > >> out after IETF52 on the loose routing proposal. > > > >> > > > >> Until it appears in the archive, you can find it at > > > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt > > > >> or > > > >> http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html > > > >> > > > >> > > > >> RjS > > > >> > > > >> _______________________________________________ > > > >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > >> This list is for NEW development of the core SIP Protocol > > > >> Use sip-implementors@cs.columbia.edu for questions on current sip > > > >> Use sipping@ietf.org for new developments on the application of sip > > > >> > > > > > > > >_______________________________________________ > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >This list is for NEW development of the core SIP Protocol > > > >Use sip-implementors@cs.columbia.edu for questions on current sip > > > >Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 11:48:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16323 for ; Mon, 21 Jan 2002 11:48:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17193 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 11:48:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15432; Mon, 21 Jan 2002 11:14:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15406 for ; Mon, 21 Jan 2002 11:14:36 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14477 for ; Mon, 21 Jan 2002 11:14:32 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0LGEYGe025120; Mon, 21 Jan 2002 11:14:35 -0500 (EST) Message-ID: <3C4C3E46.8040002@dynamicsoft.com> Date: Mon, 21 Jan 2002 11:13:58 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] Open Issue #290: Registrar increasing registration life time References: <000301c19fcd$74acac70$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Inline. Brett Tate wrote: >>I suspect there are zero existing UA's that >>ever include an expires less than one hour. >> > > I am aware of some that allow configuration > values of less than one minute (even without > clear indication that the units are in > seconds). Sure, but in actual usage I believe most are using 3600s. >>So, to summarize: >> >>1. registrars can't increase the interval >>2. registrars must not reject registrartions >>less than one hour >> > > I assume you meant 'more' instead of 'less' in > the above sentence? Yes, sorry. > > >>3. registrars may reject registrations less >>that one hour, with some TBD response code >> > > Registrars choosing to return this, would > break Robert's example of using the REGISTER's > expiration for indicating temporarily > reach me on conference room phone. > However I guess that would be the registrar's > decision to bar such an example or expose > itself to incorrect/malicious provisioning > of a device. Right. I suspect that the threshold for most devices will be less than 3599 anyway ;) All we need is a discussion in bis to make sure people are aware that expiring registrations is needed for specific services, and that the duration may not be arbitrary. > > >>May I please hear a yea/nea from the people >>in this thread?? >> > > Sounds fine to me. Great! > > Can the bis please suggest what should happen > when a 400 response is received for a REGISTER? > This maybe would give a little encouragement > to vendors to quit retrying or back off to > retrying no more than once every 30 minutes > after getting a few 400's (or unknown 4xx's). > I mention it in case item 3 turns a new response > code instead of a 403. Such text is already in bis. In 23.4, it says: 4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the 4257 same request without modification (e.g., adding appropriate authorization). However, the same request to a 4258 different server might be successful. 4259 i.e., if you get any 4xx, you have to change the request before resubmitting it. That covers your 401 case as well. Robert Sparks wrote: > > It would be good to specifically capture that registrars mustn't reject > the request only because they wanted the expiration to be longer > (we still want to be able to return 401s, 503s, etc). Right. > > I would ask to make this a SHOULD and not a MUST. In no version > of the spec to date has there been a requirement that I, as a registrar, > MUST accept a registration of a given duration - I've always had > the option to refuse it if it violated some policy of mine. > A MUST here also builds another good candidate for future-failure > (those places where we have pain fixing problems in the future because > of backwards compatibility). Do you really want to close off the > functionality of the TBD response below to long expirations forever? > Or would it be better to recommend the hour threshold and have > implementors anticipating change? I think SHOULD is OK. > > That said, don't hold up closing it based on these comments. I think we are done with this one. Text for it will appear in bis-06. It will require the usage of a new response code (423), and a new header in that error response to indicate the minimum desired interval (probably Min-Expires). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 11:56:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16690 for ; Mon, 21 Jan 2002 11:56:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA17516 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 11:56:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16375; Mon, 21 Jan 2002 11:34:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16344 for ; Mon, 21 Jan 2002 11:34:33 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15838 for ; Mon, 21 Jan 2002 11:34:16 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0LGYQGe025169; Mon, 21 Jan 2002 11:34:26 -0500 (EST) Message-ID: <3C4C42ED.1060402@dynamicsoft.com> Date: Mon, 21 Jan 2002 11:33:49 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] Comments on "unify" draft References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > Hi, > > Below are some comments in no particluar order on: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt Thanks for the comments. In general, it would be helpful to get general feedback of the form "seems like the right direction". Particularly, the main thing I need feedback on ASAP is the proposal to pretty much keep this all out of bis. The only thing in bis would be some generalized statement of when you can see offers and answers, so that we can separate the EM/manyfolks/herfp solutions from bis. Granted, this stuff still needs to be on the fast track for 3g, but I want to get it separated from bis. > > 1) Page 17 2nd paragraph discusses the benefit of communicating > progress > of a forked request from each UAS all the way back to the UAC. There > are > potentially serious privacy concerns here. I would like to see these > addressed. Specifically, it should be none of the UACs business if one > of > the branches returns a 486 Busy Here. The draft doesn't preclude sending a 486 busy. But, the UAS doesn't know if that response will be received or not by the UAC. It depends on whether there was a forking proxy or not in front of it. I guess I don't see the issue (at least, it has nothing to do with herfp). > > 2) It may seem obvious, but it would be nice to mention that this > proposal > only solves the HERFP problem for dialogs initiated with INVITE. you > may > want to summarize the proposed solution for other dialog initiating > methods (ban forking for that method or define a method for returning > the > equivalent of 155). Good point. I think it works fine for other methods as well. SUBSCRIBE, for example. You can send it to update credentials for a forked SUBSCRIBE. > > 3) Page 26 2nd to last para: should clarify that Content-Dispo > preconditions would have to be replaced with Require: preconditions Its not that are replaced; manyfolks still needed the Require mechanism, and that aspect hasn't changed. > > 4) In Figure 12 on modifying codecs (could also apply to declining or > switching ports for forked early media), I see no reason why the new > offer/answer can't get sent on the PRACK/200 instead of a separate > COMET/200. In fact, this meets all the requirements for a general > offer/answer model given on Page 16 of the draft. You could also take > advantage of *answers* in PRACKs to speed up 3pcc flows. Well, here is the reason. Because of glare, there needs to be a way to allow for an offer to be rejected. That is, if A and B send a COMET to each other at the same time, there needs to be a way for that SDP to be rejected in one of the COMETs. Now, I can do that for PRACK as well (reject it in the case of glare). But, because of the atomicity of request processing, this means that the provisional response thats being acknowledged will continue to get retransmitted, and thats bad. Its an artifact of accomplishing two totally different things with the same method. Perhaps this is not deemed serious enough to worry about, and that we can tolerate the extra retransmits that would occur if it happens. But, people should be aware. > > 5) I don't like reusing the COMET method name. I like "UPDATE" because > it > updates session state, and it can't confuse UAs that support manyfolks. I don't care what the name is, but I do care that it be the same mechanism in manyfolks as in early media as in the HERFP problem, with whatever name you like. I chose COMET since it seemed partly possible to maintain a semblance of backwards compatibility with existing implementations (although I must ask - are there any?). > > 5) I'm a bit unclear on the proxy behavior proposed for 155. If all UAs > supported 155 we wouldn't need to do anything special on a proxy. For the proxies not involved in the forking service, there is no change - 155 is propagated upstream as normal. > However, what do we if one of the UASs doesn't support 155. It would > return a 420. Is the proxy required to do anything new with this? Yes. I would need to resubmit the request to the UAS w/o the Require header (it does that with a new branch). Thus, you would fallback to current behavior. I forgot to point this out, thanks. > I > could imagine a proxy packaging the response up and sending back to the > UAC as a 155, but then the dialog state is out of sync. I had thought about that. Robert and I explicitly discussed it, and we decided to not put that in this draft at the moment. It might work for a few selected responses. Perhaps the > proxy > should send 4xx errors back to the UAC in a COMET (er.. UPDATE!) > message? Egads.... > > 6) I think correlating offers and answers could get really ugly unless > we > come up with a simpler correlation mechanism (especially if > intermediaries (like ALGs or B2BUAs) are involved. > I propose that we add two parameters to the SDP MIME type: > > sdp-params = ( offer | answer ) > > offer = "offer" EQUAL sequence-number > answer = "answer" EQUAL tag > > so a complex offer/asnwer dialog might look like this: > > application/sdp;offer=1 first offer for this dialog > application/sdp;offer=1;answer=7839748 answer from 7839748 for this > offer > ...;offer=1;answer=093412 different answer from another UAS > ...;offer=2 a new offer > ...;offer=2;answer=093412 answer for this offer > > etc... Somethng like that is beginning to look like a good idea. Not sure exactly the right way to structure it. We can come up with that later. The main question to ask is whether or not bad things will happen with 3pcc? i.e., do we ever have cases where the controller turns an answer into an offer, and vice a versa? Need to work through those. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 12:00:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16921 for ; Mon, 21 Jan 2002 12:00:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18510 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 12:00:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16771; Mon, 21 Jan 2002 11:43:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16742 for ; Mon, 21 Jan 2002 11:43:33 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16152 for ; Mon, 21 Jan 2002 11:43:29 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id QAA02211; Mon, 21 Jan 2002 16:40:03 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id QAA10427; Mon, 21 Jan 2002 16:43:25 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 09:43:24 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B3716E@n0214idc1.oss.level3.com> To: dean.willis@softarmor.com Cc: sip@ietf.org Subject: RE: [Sip] Attention - comment on Loose Routing draft Date: Mon, 21 Jan 2002 09:43:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > I'll give an example that describes the problem I think > you're seeing -- I'm > probably understanding you wrong, so flame on . . . > > Ok, let's say we have established a dialog routed UA1, P1, > P2, UA2. P2 has > resources tied up. > > After some time, P1 decides to "retarget" the dialog by altering the > destination of a reINVITE issued by P1. P1 rewrites the > request-URI and/or > routes such that the reinvite traverses P3 and arrives at UA3. > > Yes, this is bad, as it leaves P2 holding resources. But it's > bogus more > ways than that . . . > I think we agree here. > But what if P1 has knowledge that P2 has failed, and it > re-routes thru P3 > in order to get to UA2, the original target? OK, if failure recovery is what you had in mind, this sounds reasonable. I would have no problem with language that makes this intent clear when allowing changed routes. As long as the language doesn't allow problems touched on above to happen. John Hearty Level3 > > -- > Dean > > ----- Original Message ----- > From: > To: > Cc: ; ; > > Sent: Friday, January 18, 2002 9:20 AM > Subject: RE: [Sip] Attention - comment on Loose Routing draft > > > > > > The UAC considers it a re-Invite even when a proxy later > re-writes the > > r-uri (a common action). I'm not clear where you are > headed with this > line > > of thought wrt Robert's draft. > > > > John Hearty > > Level3 > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Friday, January 18, 2002 7:06 AM > > To: Hearty, John > > Cc: rsparks@dynamicsoft.com; bernhard.honeisen@nokia.com; > sip@ietf.org > > Subject: Re: [Sip] Attention - comment on Loose Routing draft > > > > > > Changing the request-URI in a reinvite makes it not a > reinvite, right? > > > > -- > > Dean > > > > ----- Original Message ----- > > From: > > To: > > Cc: ; ; > > > Sent: Thursday, January 17, 2002 9:22 AM > > Subject: RE: [Sip] Attention - comment on Loose Routing draft > > > > > > > > > > I would have to disagree with you too. This sounds like trouble > brewing, > > > especially in transactions subsequent to the first. Take > for example a > > > firewall control proxy downstream from X. An initial > Invite sets up > > > firewall resources. If a re-Invite comes through and X > decides service > > > route points downstream from X don't matter anymore, you > just stranded > > > firewall resources. > > > > > > John Hearty > > > Level3 > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Thursday, January 17, 2002 3:55 AM > > > To: Honeisen Bernhard (NET/Helsinki); sip@ietf.org > > > Cc: 'ext Robert Sparks' > > > Subject: Re: [Sip] Attention - comment on Loose Routing draft > > > > > > > > > Hmm, RjS may disagree, but I think that the retargeting > of the message > at > > X > > > might override the service routing in the original > request. Changing the > > > request URI means to me "don't send it to where it was > being sent, send > it > > > to this other place instead". Given this logic, service > route points > > > downstream from X probably don't matter anymore. > > > > > > -- > > > Dean > > > > > > ----- Original Message ----- > > > From: "Honeisen Bernhard (NET/Helsinki)" > > > > To: > > > Cc: "'ext Robert Sparks'" > > > Sent: Tuesday, January 15, 2002 9:05 AM > > > Subject: RE: [Sip] Attention - comment on Loose Routing draft > > > > > > > > > > Hi RjS! > > > > > > > > Some question: > > > > > > > > Consider a situation, where a request is directed > > > > to (B) and two service elements (X) and (Y) have > > > > to be visited before. > > > > (X) performs a service, which replaces the intended > > > > destination URL, i.e. (B), whereas (Y) executes > > > > some feature, which depends on the output of (X). > > > > > > > > When the request arrives at (X), the R-URI / Route > > > > could look like: > > > > - R-URI: > > > > - Route: , > > > > (The intended destination has been appended earlier > > > > to Route as per section 5.2 in your I/D) > > > > > > > > How can (X) now apply the destination URL relacing feature? > > > > My first guess was, that (X) would modify the last entry > > > > in the Route, i.e. (B). > > > > > > > > Your first proposal in section 2 prohibits such behavior: > > > > "[...] an element [...] MUST NOT modify or remove > > > > subsequent Route header field values." > > > > > > > > Is this restriction intended also for such cases or could > > > > we relax it to allow modifying of the last entry in Route? > > > > Would marking the last Route entry as the intended > > > > destination (and allow modifying of such only) solve > > > > this issue? > > > > > > > > Greetings, > > > > Bernie > > > > > > > > > > > > PS: Some Typos: > > > > > > > > - section 5.5, F7-F12: > > > > s/Contact: sip:jbj@212.28.214.227/Contact: > sip:jbj@212.28.214.228/ > > > > > > > > - section 5.5. F3/F4: > > > > - Shouldn't maddr in F4 contain a different IP-address > > > > than in F3? > > > > - Maybe add a FQDN <-> IP mapping table to ease > > > > the understanding of the examples. > > > > > > > > - section 5.8: > > > > s/senting/sending/ > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > > >Sent: 14. January 2002 20:58 > > > > >To: 'sip@ietf.org' > > > > >Subject: [Sip] Attention - comment on Loose Routing draft > > > > > > > > > > > > > > >The draft below contains the resolution to a large > > > > >set of open issues around processing of the Route header, > > > > >preloaded routes, and the use of default outbound proxies. > > > > >The plan is to modify bis to reflect these proposals. > > > > > > > > > >Please review it as soon as you can and comment if you > > > > >see real problems. Silence will be taken as consent. > > > > > > > > > >RjS > > > > > > > > > >> -----Original Message----- > > > > >> From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > > >> Sent: Thursday, January 10, 2002 10:46 PM > > > > >> To: 'sip@ietf.org' > > > > >> Subject: [Sip] Loose Routing draft > > > > >> > > > > >> > > > > >> I just submitted a draft refining the post I sent > > > > >> out after IETF52 on the loose routing proposal. > > > > >> > > > > >> Until it appears in the archive, you can find it at > > > > >> > http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt > > > > >> or > > > > >> > http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html > > > > >> > > > > >> > > > > >> RjS > > > > >> > > > > >> _______________________________________________ > > > > >> Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > > >> This list is for NEW development of the core SIP Protocol > > > > >> Use sip-implementors@cs.columbia.edu for questions > on current sip > > > > >> Use sipping@ietf.org for new developments on the > application of sip > > > > >> > > > > > > > > > >_______________________________________________ > > > > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > >This list is for NEW development of the core SIP Protocol > > > > >Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > >Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > > > > > > > > > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 12:06:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17103 for ; Mon, 21 Jan 2002 12:06:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18911 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 12:06:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16547; Mon, 21 Jan 2002 11:40:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16517 for ; Mon, 21 Jan 2002 11:40:19 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16025 for ; Mon, 21 Jan 2002 11:40:15 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0LGdiGe025173; Mon, 21 Jan 2002 11:39:44 -0500 (EST) Message-ID: <3C4C442B.8080906@dynamicsoft.com> Date: Mon, 21 Jan 2002 11:39:07 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: "Henning G. Schulzrinne" , Dorgham Sisalem , sip@ietf.org Subject: Re: [Sip] MAJOR Open Issue #184: Message size limitations References: <3C47CAC4.CDE24EE1@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > Just a small comment on point (1). A case where the response may be much > bigger than the request is when we send an INVITE without SDP, and > receive a 200 with SDP. Now, I am NOT saying this is a problem, and it > could probably also be classified as "in most cases it won't happen". Actually, it is a common case for 3pcc. Nonetheless, I still feel the proposal is a reasonable point of compromise, covering a good number of conditions without doing substantial damage to SIP. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 12:07:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17127 for ; Mon, 21 Jan 2002 12:07:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA18955 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 12:07:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17288; Mon, 21 Jan 2002 11:49:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17258 for ; Mon, 21 Jan 2002 11:49:41 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16373 for ; Mon, 21 Jan 2002 11:49:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0LGmsGe025185; Mon, 21 Jan 2002 11:48:54 -0500 (EST) Message-ID: <3C4C4652.1060009@dynamicsoft.com> Date: Mon, 21 Jan 2002 11:48:18 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Dean Willis , Juha Heinanen , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C485371.4E2893A6@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning G. Schulzrinne wrote: > Dean Willis wrote: > >>No, because quite probably if you're visiting someone else's corporate >> > SIP > >>phone, the gateway that will (perhaps MUST) be used for PSTN >> > termination is > >>the local gateway, not the one back in your home domain. >> > > Why is that? In most cases, I would certainly prefer to use my own phone > service, rather than the hotel phone service, for example. First off, I agree with Hennings proposed text, which read: > > To make my proposal more concrete: If I log in as foo@example.com, my > home domain is example.com and this home domain will be used for > registrations and default domain for E.164 numbers (and maybe for > preloaded routes, if that matters). > With the caveat that I believe this should apply NOT just for numbers, but for any entered data which is not otherwise qualified. That is, if I enter "bob", and the UA doesn't know what else to do with it (no match in address book, etc.), it uses example.com. This mirrors my email client behavior exactly. Now, I should also point out that this rule ONLY applies when the UA doesn't have policy to specify otherwise. I see nothing wrong with having a button that says "resolve this in my visited domain", or an explicit policy at the UA which prefers tel URL. The point of this requirement is to define behavior in the absence of any explicitly defined policy. You can still have policies to support local resolution of addresses if you want (and indeed, you do want that for things like 411). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 12:21:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17503 for ; Mon, 21 Jan 2002 12:21:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19365 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 12:21:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16954; Mon, 21 Jan 2002 11:44:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16847 for ; Mon, 21 Jan 2002 11:44:43 -0500 (EST) Received: from localhost ([218.55.130.22]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16175 for ; Mon, 21 Jan 2002 11:44:37 -0500 (EST) Message-Id: <200201211644.LAA16175@ietf.org> Reply-To: naracom2002@naver.com From: Ä£±¸¿¡°Ô To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 22 Jan 2002 01:47:02 +0900 Subject: [Sip] ¾È³çÇϼ¼¿ä[È«º¸] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org ¼±ºÒ¿ä±ÝÁ¦ ÂüÁ¶ÀÚ·áÁý

¾È³çÇϼ¼¿ä ÀúÈ£ÁØÀÌ¿¡¿ä
ÀßÁö³»°í °è½ÃÁ®?
ÁÁÀºÁ¤º¸°¡ ÀÌ·¸°Ô ¸áº¸³» µå·Á¿ä
Çѹø ²Ä²ÄÈ÷ µûÁ®º¸¼¼¿ä ¾Æ¸¶ ¸¹Àºµµ¿òµÉ°Å¿¡¿ä
¾Æ·¡¿¡ ÆÄÀÏ÷ºÎÇßÀ¸´Ï Àо½Ã°í¿ä
±×·³ ¶Ç ¸áµå¸±²²¿ä








¼±ºÒ¿ä±ÝÁ¦¼­ºñ½º´Â ¾î´À³¯ °©Àڱ⠳ª¿Â ¼­ºñ½º°¡ ¾Æ´Ñ, ¼±Áø ¿©·¯³ª¶ó¿¡¼­´Â ÀÌ¹Ì ±âÁ¸¿¡ ½Ç½ÃÇÏ°í´Â ¼­ºñ½º·Î ȸ»çÀÇ ÀÔÀå¿¡¼­´Â ¾ÈÁ¤ÀûÀÌ¸ç ¹Ì³³ °ÆÁ¤ÀÌ ¾ø´Â ȸ¿øÀ¯Ä¡¸¦ ÇÏ¿© ȸ»çÀÇ ¾ÈÁ¤¼ºÀ» ²ÒÇÒ ¼ö ÀÖÀ¸¸ç, ÀÌ¿¡µû¸¥ °í°´Àº °¢Á¾ ÇýÅà ¹× ¼ö´çÀ» ¹Þ´Â °ÍÀÔ´Ï´Ù.
Áï ¼±ºÒÁ¦¿ä±ÝÁ¦¶õ ¸ÕÀú ÀÏÁ¤ºÎºÐÀÇ Åë½Å·á¸¦ ³»°í ij½¬¹é(Çö±Ý)°ú ±âŸ ¼ö´çÀ» ¹Þ´Â ¿ä±Ýü°èÀ̸ç, ÀÌ·ÎÀÎÇÑ ÇýÅÃÀ» °í°´¿¡°Ô Å©°Ô´Â 35%¿¡ ÇØ´çµÇ´Â ºÎºÐÀ» ´Ù½Ã Çö±ÝÀ¸·Î µ¹·Áµå¸®°í ÀÖ½À´Ï´Ù.
 

1. ¾Ç¼º¿¬Ã¼ ¿ä±ÝÀ¸·Î ÀÎÇÑ ±ÝÀ¶ ½Å¿ëºÒ·®ÀÚÀÇ Áõ°¡.
2. ÀÎÀû, ¹°ÀûÀ¸·Î ¸¹Àº °ü¸®ºñ¿ë ÇÊ¿ä (¿ä±Ý°íÁö, ä±Ç°ü¸® µî).
3. À̵¿Åë½Å »ç¿ëÀÚ°¡ »ç¿ë¿ä±ÝÀÇ ÀÎÁö¾øÀÌ ¹«ºÐº°ÇÑ »ç¿ëÀ¸·Î ÀÎÇÑ °ú¼Òºñ ÃÊ·¡.

ÀÌ·¯ÇÑ, ¹®Á¦·Î ÀÎÇØ ¼¼°èÀûÀ¸·Î À̵¿Åë½ÅÀº ¼±ºÒ¿ä±ÝÁ¦·Î ÀüȯµÇ°í ÀÖ½À´Ï´Ù.
¡Ø 2002³â¿¡´Â IMT2000 ¼­ºñ½º°¡ ½ÃÀ۵Ǹç, ±×¶§´Â Áö±Ý »ç¿ë¿ä±ÝÀÇ 3~4¹è¿¡ À̸£´Â ¼­ºñ½º ¿ä±ÝÀÌ »ç¿ëµÉ °ÍÀ̶ó°í ¿¹ÃøÇÏ°í ÀÖ½À´Ï´Ù. Åë½Å½ÃÀåÀÌ °³¹æµÇ¾úÀ½¿¡µµ ºÒ±¸ÇÏ°í, ¿Ü±¹ÀÇ °Å´ëÅë½Å±â¾÷µéÀÌ Áö±Ý ÀáÀáÇÑ°ÍÀº ¹Ù·Î ÀÌ IMT2000 ½Ã´ëÀ» ±â´Ù¸®¸ç, ¿ì¸®³ª¶ó Åë½Å½ÃÀåÀ» ³Ñº¸°í ÀÖ´Â °ÍÀÔ´Ï´Ù.

: °³Àδ븮Á¡À¸·Î ±¸¼º
°íÁ¤µÈ Áö¿ª ´ë¸®Á¡À» Å»ÇÇÇÏ¿© Áö¿ª¿¡ »ó°ü¾øÀÌ ¿òÁ÷ÀÌ´Â ´ë¸®Á¡À¸·Î ±¸¼º
¡¡

ÀϹݴ븮Á¡

KTF ¼±ºÒ´ë¸®Á¡

¹ü        À§

Áö¿ªº° ÇÑ°è Áö¿ª Á¦ÇѾøÀÌ Àü±¹
½Ã        ¼³ ¸ÅÀå ÀÓ´ë (º¸Áõ±Ý + ½Ã¼³ºñ µî) ¸ÅÀå ºÒÇÊ¿ä
´ã        º¸ ´Ü¸»±â ±¸¸Å¸¦ À§ÇØ ´ãº¸¹° Á¦°ø ´ãº¸ ¾øÀ½
°ü ¸® À¯ Áö °ü¸® Àοø ¹× °ü¸®ºñ °ú´Ù ÁöÃâ ¾øÀ½
¼ö   ¼ö   ·á °ü¸®¼ö¼ö·á ȸ¿øÀå·Á±Ý
½Ã   Àå   ¼º ½ÃÀ强ÀÌ ¾ø´Ù. (Æ÷È­»óÅÂ) ¹«ÇÑÇÑ ½ÃÀ强 (Ãʱâ½ÃÀå ¼±Á¡)
ÇØ   Áö   À² °í°´ À̵¿ÀÌ ¸¹´Ù.

(´ë¸®Á¡°£ °ø¿ë½Ã½ºÅÛ)		 °í°´À̵¿ ¾øÀ½.

(Àü¿ë½Ã½ºÅÛ)
     

 ¢º »ç¿ëÀÌ ºÒÆíÇÏ´Ù : Á¢¼Ó¹øÈ£¿Í  Ä«µå¹øÈ£¸¦ ÀÔ·ÂÇÑ ÈÄ »ç¿ëÇÏ¿©¾ß ÅëÈ­°¡ ¿¬°áµË´Ï´Ù.
 ¢º ½Ã¿ÜÀüÈ­ : ±â¾÷, ȸ»ç¿¡¼­ ¸¹ÀÌ »ç¿ë (¾à 2Á¶¿ø)  °³ÀÎÀº 1°¡±¸´ç ¾à 4,600¿ø »ç¿ë
 ¢º ±¹Á¦ÀüÈ­ : ±â¾÷, ¹«¿ªÈ¸»ç, ¿ÀÆÄ»óµîÀÌ ¸¹ÀÌ »ç¿ë (¾à1Á¶¿ø) °³ÀÎ »ç¿ëÀº ¹ÌºñÇÏ´Ù.

     
   ¢º »ç¿ëÀÌ Æí¸®ÇÏ´Ù. : ÈÄºÒ ÀüÈ­ »ç¿ë°ú µ¿ÀÏ
 ¢º 2,750¸¸¸íÀÌ ³Ñ´Â ´ëºÎºÐÀÇ °í°´ÀÌ °³ÀÎÀ¸·Î ±¸¼ºµÇ¾î ÀÖ½À´Ï´Ù.
 ¢º ¼±ºÒ½ÃÀåÀº ¹«ÇÑÇÕ´Ï´Ù. : 2750¸¸ Èĺҿä±Ý »ç¿ë°í°´
 ¢º 1°¡±¸´ç 11¸¸¿ø ÀÌ»ó »ç¿ëÇÕ´Ï´Ù. (1999³â Åë°è)
¿ä±Ý»óÇ° ÀÏ ±âº»·á ¿ù ±âº»·á ±¹³»ÅëÈ­·á 
(¿ø/10ÃÊ)		 ºñ °í
Æò»ó ÇÒÀÎ ½É¾ß
¼±ºÒ Ç¥ÁØ 533 ¿ø 16,000 ¿ø 18 ¿ø 15 ¿ø 10 ¿ø ¡¡
¼±ºÒ ¿¡À̽º 616 ¿ø 18,500 ¿ø 15 ¿ø 14 ¿ø 13 ¿ø ¡¡
¼±ºÒÇÁ¸® 200 1,183 ¿ø 35,500 ¿ø 17 ¿ø 14 ¿ø 10 ¿ø 200ºÐ ¹«·á

  ¢º ¿ä±Ý»óÇ° º¯°æ½Ã Àû¿ë½ÃÁ¡ : º¯°æ°ú µ¿½Ã¿¡ º¯°æ¿ä±ÝÀ¸·Î Á¤»êµÇ³ª, ¿ù 1ȸ¿¡ ÇÑÇÔ.
  ¢º ÇÒ ÀÎ ½Ã °£
    1) ¼±ºÒÇ¥ÁØ, ¼±ºÒ¿¡À̽º ¿ä±ÝÀÇ °æ¿ì
       - ÆòÀÏ (Åä¿äÀÏ Æ÷ÇÔ) : 0 ~ 6 ½Ã (½É¾ß) / 6 ~ 12 (ÇÒÀÎ) / 12 ~ 24 (Æò»ó)     
       - °øÈÞÀÏ (ÀÏ¿äÀÏ Æ÷ÇÔ) : 0 ~ 6½Ã (½É¾ß) / 6 ~ 24 (ÇÒÀÎ)
     2) ¼±ºÒÇÁ¸® 200 ¿ä±ÝÀÇ °æ¿ì
       - ÆòÀÏ (Åä¿äÀÏ Æ÷ÇÔ) : 0 ~ 6 ½Ã (½É¾ß) / 6 ~ 8, 21 ~ 24 (ÇÒÀÎ) / 8 ~ 21 (Æò»ó)
       - °øÈÞÀÏ (ÀÏ¿äÀÏ Æ÷ÇÔ) : 0 ~ 6½Ã (½É¾ß) / 6 ~ 24 (ÇÒÀÎ)


 KTF(Çѱ¹Åë½ÅÇÁ¸®ÅÚ)ÀÇ Åº»ý ´ç½ÃºÎÅÍ ¸ðµç ½Ã½ºÅÛÀ» ´ã´çÇØ ¿Â  ´ë¿ìÁ¤º¸½Ã½ºÅÛÀº 
 ±âÁ¸ ÀüÀÚ»ó°Å·¡ÀÇ ±â¹ÝºÎÀç·Î ¿À´Â ÀûÀÚ¿äÀÎÀ» ÁÖ½Äȸ»ç ³ª¶óÄÞÀÇ ³×Æ®¿öÅ© ¸¶ÄÉÆÃÀ»  
 ÅëÇÏ¿© ÃִܱⰣ ÃÖ´ëȸ¿øÀÇ ±â¹ÝÈ®º¸¸¦ ¸ñÇ¥·Î  KTF, ´ë¿ìÁ¤º¸½Ã½ºÅÛ, ÁÖ½Äȸ»ç
 ³ª¶óÄÞÀÇ Àü·«Àû Á¦ÈÞ¸¦ ÅëÇÏ¿© 
 ¼±Áø±¹Çü ¼±ºÒ¿ä±ÝÁ¦µµ
- KTF 016 ¼±ºÒ¿ä±ÝÁ¦µµ -
¸¦  ź»ý½ÃÄ×½À´Ï´Ù.

E-mail : corud2@dreamwiz.com
  
±ÍÇÏÀÇ E-MAILÀº °ü·Ã °Ô½ÃÆÇÀ» ÅëÇØ ¾Ë°Ô µÇ¾ú½À´Ï´Ù.
¿øÄ¡ ¾Ê¾Ò´ø ¸ÞÀÏÀ̶ó¸é ¿©±â¸¦ ´­·¯ ¾Ë·Á ÁÖ½Ã¸é ¾ÕÀ¸·Î´Â ¹ß¼ÛµÇÁö ¾Êµµ·Ï ÇÏ°Ú½À´Ï´Ù.

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 21 12:56:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18670 for ; Mon, 21 Jan 2002 12:56:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA20668 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 12:56:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20117; Mon, 21 Jan 2002 12:38:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20088 for ; Mon, 21 Jan 2002 12:38:41 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17938 for ; Mon, 21 Jan 2002 12:38:38 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.23]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0LHcXGe025218; Mon, 21 Jan 2002 12:38:33 -0500 (EST) Message-ID: <3C4C51F4.9050702@dynamicsoft.com> Date: Mon, 21 Jan 2002 12:37:56 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Christer Holmberg CC: "Vijay K. Gurbani" , rsparks@dynamicsoft.com, james.yu@neustar.com, SIP WG List Subject: Re: [Sip] Issues with telephone-subscriber appearing in a SIP References: <3C4B20E5.AF3CA615@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > First, I must also admit that I haven't followed the discussion, and > wasn't aware about the issue until Paris. > > Like Vijay, I would vote for (2). I think we need to consider the pros/cons of that. I only vaguely remember the email discussion that led to the conclusion to put them in the user part. Certainly, collision of params is one part. Another part is URI comparison; it becomes harder with them as params, since one element that doesn't understand tel would ignore the params, whereas they would be needed for comparison of the tel URL itself. Thus, equivalency would be different as a sip URL v. a tel URL, which seems wrong. > > However, I strongly dissagree that the parameters should be allowed in > the user part, unless they are treated like parameters. By saying that > servers which don't understand the parameters should just treat the > whole user part as a string will cause problems. No, I don't think that is the proposal. If you need to process the URI, the user=phone part is there for you do the proper analysis. That has always been the case. The issue is that there are elements that will need to do blind URI equality comparisons, without otherwise processing the URI, and that supporting those is the issue. > > For example, assume that a PSTN gateway is able to route the number > "12345" to the PSTN network. > > Now, if it receives sip:12345;parm1=XXX@myGateway.com, and it treats the > user part as a string, it would try to route "12345;parm1=XXX" to the > PSTN network, and that would obviously not work. If it would be able to > separate "parm1=XXX" as parameters, however, it would be able to route > "12345" to the PSTN network - no matter if it understands the parm1 > parameter or not. Right - exactly why it shouldn't do this, and instead look at user=phone an thus parse the user part as telephone-subscriber, which defiens all these params. > So, assuming we want to be able to have the parameters in the user part, > the options I can come up with are: > > 1. We specify that user=phone means the server MUST treat the SIP-URI > user part as a TEL-URL (this is the same as proposal (1)). > > 2. We define a Require header option-tag, which requires the server to > treat the SIP-URI user part as a TEL-URL. You can't use Require, since you are assuming the context of this is a SIP request. They could appear anywhere. The URI must be usable by itself. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Mon Jan 21 18:59:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28514 for ; Mon, 21 Jan 2002 18:59:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA02663 for sip-archive@odin.ietf.org; Mon, 21 Jan 2002 18:59:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02161; Mon, 21 Jan 2002 18:40:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02126 for ; Mon, 21 Jan 2002 18:40:40 -0500 (EST) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28209 for ; Mon, 21 Jan 2002 18:40:36 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0LNedQ02645; Mon, 21 Jan 2002 18:40:39 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA12148; Mon, 21 Jan 2002 17:40:34 -0600 (CST) Message-ID: <3C4CA6F9.58BD32B4@lucent.com> Date: Mon, 21 Jan 2002 17:40:41 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories/Lucent Technologies, Inc X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Christer Holmberg , rsparks@dynamicsoft.com, james.yu@neustar.com, SIP WG List Subject: Re: [Sip] Issues with telephone-subscriber appearing in a SIP References: <3C4B20E5.AF3CA615@lmf.ericsson.se> <3C4C51F4.9050702@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Christer Holmberg wrote: > > > Hi, > > > > First, I must also admit that I haven't followed the discussion, and > > wasn't aware about the issue until Paris. > > > > Like Vijay, I would vote for (2). > > I think we need to consider the pros/cons of that. I only vaguely > remember the email discussion that led to the conclusion to put them in > the user part. Certainly, collision of params is one part. Another part > is URI comparison; it becomes harder with them as params, since one > element that doesn't understand tel would ignore the params, whereas > they would be needed for comparison of the tel URL itself. Thus, > equivalency would be different as a sip URL v. a tel URL, which seems wrong. Namespace collision could be mitigated by the LNP I-D (when it becomes a RFC) defining a protected namespace for these parameters. Regarding equivalency being different on a SIP URL vs. a tel URL, isn't that what we want? In other words, sip:+1-202-533-1234;rn=+1-202-544-0000;npdi=yes@xxx.yyy.biz;user=phone and tel:+1-202-533-1234;rn=+1-202-544-0000;npdi=yes will not be treated the same anyway since the scheme (sip:, tel:) does not match. On a SIP URL containing a E.164 number, I do not see any problems in URL comp- arision if the parameters appear at the end (R-URI parameters). That is, given a SIP URL: sip:+1-202-533-1234@xxx.yyy.biz;user=phone;rn=+1-202-544-0000;npdi=yes the normal URL matching rules would apply; i.e. the scheme has to match, the user part has to match, the domain has to match, and the parameters have to match. SIP entities that do not know anything about the parameters "npdi" and "rn" can still match the name of the parameter ("npdi", "rn") and the octets that appear as the value of these parameters. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 22 04:09:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14199 for ; Tue, 22 Jan 2002 04:09:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA27872 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 04:09:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27029; Tue, 22 Jan 2002 03:52:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26997 for ; Tue, 22 Jan 2002 03:52:31 -0500 (EST) Received: by ietf.org (8.9.1a/8.9.1a) id DAA13971; Tue, 22 Jan 2002 03:52:29 -0500 (EST) Date: Tue, 22 Jan 2002 03:52:29 -0500 (EST) Message-Id: <200201220852.DAA13971@ietf.org> X-Authentication-Warning: ietf.org: majordom set sender to Majordomo-Owner@ietf.org using -f To: sip@ietf.org From: Majordomo@ietf.org Reply-To: Majordomo@ietf.org Subject: [Sip] Confirmation for subscribe ietf Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "ietf@ietf.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@ietf.org": auth ed87fdf6 subscribe ietf sip If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth ed87fdf6 subscribe ietf \ sip If you have any questions about the policy of the list owner, please contact "ietf-approval@ietf.org". Thanks! Majordomo@ietf.org _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 22 04:09:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14219 for ; Tue, 22 Jan 2002 04:09:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA27892 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 04:10:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26965; Tue, 22 Jan 2002 03:51:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26933 for ; Tue, 22 Jan 2002 03:51:21 -0500 (EST) Received: by ietf.org (8.9.1a/8.9.1a) id DAA13959; Tue, 22 Jan 2002 03:51:19 -0500 (EST) Date: Tue, 22 Jan 2002 03:51:19 -0500 (EST) Message-Id: <200201220851.DAA13959@ietf.org> X-Authentication-Warning: ietf.org: majordom set sender to Majordomo-Owner@ietf.org using -f To: sip@ietf.org From: Majordomo@ietf.org Reply-To: Majordomo@ietf.org Subject: [Sip] Confirmation for subscribe ietf-announce Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "ietf-announce@ietf.org". If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@ietf.org": auth 5d35e9ed subscribe ietf-announce sip If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth 5d35e9ed subscribe ietf-announce \ sip If you have any questions about the policy of the list owner, please contact "ietf-announce-approval@ietf.org". Thanks! Majordomo@ietf.org _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 22 04:41:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14557 for ; Tue, 22 Jan 2002 04:41:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA29144 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 04:42:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28132; Tue, 22 Jan 2002 04:19:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28098 for ; Tue, 22 Jan 2002 04:19:05 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14347 for ; Tue, 22 Jan 2002 04:18:59 -0500 (EST) From: bernhard.honeisen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0M9J4908618 for ; Tue, 22 Jan 2002 11:19:04 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jan 2002 11:19:01 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 22 Jan 2002 11:19:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [Sip] Loose Routing draft MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 22 Jan 2002 11:19:00 +0200 Message-ID: Thread-Topic: [Sip] Loose Routing draft Thread-Index: AcGar96h8KnuoAaiEdapbwBQi2kYTQIdHvkw To: Cc: X-OriginalArrivalTime: 22 Jan 2002 09:19:01.0179 (UTC) FILETIME=[D42B00B0:01C1A325] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA28099 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Robert! Comments inline: cheers, Bernie >-----Original Message----- >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: 11. January 2002 16:54 >To: Honeisen Bernhard (NET/Helsinki); Robert Sparks; sip@ietf.org >Subject: RE: [Sip] Loose Routing draft > > > > >> -----Original Message----- >> From: bernhard.honeisen@nokia.com >[mailto:bernhard.honeisen@nokia.com] >> Sent: Friday, January 11, 2002 7:54 AM >> To: rsparks@dynamicsoft.com; sip@ietf.org >> Subject: RE: [Sip] Loose Routing draft >> >> >> Hi Robert et al.! >> >> Intersting I/D! It looks like, that we have a solution >> for the problem. >> >> I have a couple of questions/comments: >> >> I assume this new procedure can be applied for initial and >> subsequent requests. Is this assumention correct? > >Yes it can. Note that different policies can be applied to initial >and subsequent requests (so you could loose-route the initial and >strict-route subsequents if that's what you wanted to do). How can a proxy make the difference between an initial INVITE and a re-INVITE? I have a feeling, that checking the To tag is not the best solution. Neither it is a good solution, if proxies need to keep session state. What other possibilities are there? >> Is there a requirement, that loose routing is needed in >> subsequent requests? > >There are people that want to be able to do this. > >> >> What would be the impact, if we allow a local policy >> (as described in your I/D) for the INITIAL request ONLY, >> and leave subsequent requests as before (i.e. strict >> source routing). >> Or in other words: Apply this local policy for >> pre-loaded route headers only. > >We don't preclude that policy but I don't believe we should >require it. I would go one step further, and at least discourage people from loose-routing _subsequent_ requests (e.g. re-INVIVEs). >> Therefore we could introduce a new Route parameter, which >> informs about, that the Routing can be loose, or has >> to be strict. >> >> e.g. Route: proxyA@networkB.com; routing=loose >> (or similar) > >There's a problem with who knows when to include such an >indicator. If you are an endpoint, you don't know what >the service you are trying to use might need to do (unless >the service has told you through some mechanism like PATH, >in which case the service can manage its own policy) > >> >> New proxy implementations would route strict, if no >> such paramenter present and apply the local policy >> only of this parameter present. >> Older proxy implementations would simply ignore this >> new parameter. >> >> I see the following advantages of my proposal: >> >> - Changes to existing SIP are fewer >> (only the new case of pre-loaded route headers >> in initial request would be affected) >> - more backwards compatibility >> - Less new error cases (can apear only during session >> first INVITE) >> >> - Pre-loaded Route headers can be defined as >> "loose" or as "strict" >> >> >> I am looking forward for comments on this proposal! >> >> cheers, >> Bernie >> >> >> >-----Original Message----- >> >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] >> >Sent: 11. January 2002 6:46 >> >To: sip@ietf.org >> >Subject: [Sip] Loose Routing draft >> > >> > >> >I just submitted a draft refining the post I sent >> >out after IETF52 on the loose routing proposal. >> > >> >Until it appears in the archive, you can find it at >> >http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.txt >> >or >> >http://www.nostrum.com/~rjsparks/draft-sparks-sip-looseroute-00.html >> > >> > >> >RjS >> > >> >_______________________________________________ >> >Sip mailing list http://www1.ietf.org/mailman/listinfo/sip >> >This list is for NEW development of the core SIP Protocol >> >Use sip-implementors@cs.columbia.edu for questions on current sip >> >Use sipping@ietf.org for new developments on the application of sip >> > >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 22 10:09:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25456 for ; Tue, 22 Jan 2002 10:09:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12187 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 10:09:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11149; Tue, 22 Jan 2002 09:52:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11113 for ; Tue, 22 Jan 2002 09:52:45 -0500 (EST) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20573 for ; Tue, 22 Jan 2002 09:52:35 -0500 (EST) Received: from hermes.ee.surrey.ac.uk ([131.227.88.10] ident=exim) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 16T2Hn-0000m7-00 for sip@ietf.org; Tue, 22 Jan 2002 14:52:31 +0000 Received: from ees2ll (helo=localhost) by hermes.ee.surrey.ac.uk with local-esmtp (Exim 2.12 #5) id 16T2Hm-0006YN-00 for sip@ietf.org; Tue, 22 Jan 2002 14:52:30 +0000 Date: Tue, 22 Jan 2002 14:52:30 +0000 (GMT) From: Lei Liang X-X-Sender: ees2ll@hermes.ee.surrey.ac.uk To: sip@ietf.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan *16T2Hn-0000m7-00*FNweMz0aqKU* (SECM, UniS) Subject: [Sip] cooperate with Megaco? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, guys, I see in Megaco the MGC support SDP and SIP. but I don't know how exactly it works. is there idea to handle this problem in SIP consideraton? I also wondered how SIP is translated to a PSTN handset. is there any specification in the bis-05? thanks a lot. lei _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 22 10:21:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26089 for ; Tue, 22 Jan 2002 10:21:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12571 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 10:21:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09030; Tue, 22 Jan 2002 09:33:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08952 for ; Tue, 22 Jan 2002 09:33:43 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19595; Tue, 22 Jan 2002 09:33:38 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0MEXeio031242; Tue, 22 Jan 2002 16:33:40 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15437.30788.503087.167965@harjus.eng.song.fi> Date: Tue, 22 Jan 2002 16:33:40 +0200 To: sipping@ietf.org CC: sip@ietf.org X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Subject: [Sip] problem with sip resonse code mapping to isup Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit if i try to call from pstn to a sip phone that is not currently registered, the home proxy of the phone returns "404 not found". according to draft-ietf-sipping-isup-00.txt the sip/isup gw then maps that to "1 Unallocated number". i think this is plain wrong, because surely the number has been allocated to the sip phone. the phone just happens to be off-line. in finland pstn turns "1 Unallocated number" into a voice reply that goes something like "the number doesn't exist, please check the number and try again". from that the called gets the wrong impression that he has got a wrong number. if i call to a cell phone that happens to be offline, i get from pstn a message that goes something like "the number you tried to call is not currently reachable, please try again later". i believe this is generated from "18 No user responding". i would like to get this same announcement if i call a sip phone whose number is not currently registered, but which the proxy knows exists in its domain. according to the table in draft-ietf-sipping-isup-00.txt, i can get "18 No user responding" if the proxy would return "480 Temporarily unavailable". this however, is not possible according to bis-05: 23.4.16 480 Temporarily Unavailable The callees end system was contacted successfully but the callee is currently unavailable (e.g., not logged in, logged in in such a manner as to preclude communication with the callee or activated the do not disturb feature). i.e., only the phone, not the proxy, can return such a message, but obviously in this case it can't because proxy doesn't know where the phone is and thus can't forward the invite to it. clearly something needs to be done in order to resolve this issue. i'll include also the sip list, since it would be possible to do the fix in either document. my initial feeling is that we would need a new error response "4xx Offline", alternatively we need to change the wording of 404, because now 404 should be returned if the "user doesn't exist", which to very ambiguous to me. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 22 10:49:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27283 for ; Tue, 22 Jan 2002 10:49:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14206 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 10:49:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12943; Tue, 22 Jan 2002 10:29:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12914 for ; Tue, 22 Jan 2002 10:29:12 -0500 (EST) Received: from web11608.mail.yahoo.com (web11608.mail.yahoo.com [216.136.172.60]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26419 for ; Tue, 22 Jan 2002 10:29:09 -0500 (EST) Message-ID: <20020122152911.14410.qmail@web11608.mail.yahoo.com> Received: from [208.237.135.12] by web11608.mail.yahoo.com via HTTP; Tue, 22 Jan 2002 07:29:11 PST Date: Tue, 22 Jan 2002 07:29:11 -0800 (PST) From: Sean Olson Subject: RE: [Sip] Loose Routing draft To: bernhard.honeisen@nokia.com, sip@ietf.org Cc: rsparks@dynamicsoft.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > How can a proxy make the difference between an > initial INVITE > and a re-INVITE? > I have a feeling, that checking the To tag is not > the best solution. > Neither it is a good solution, if proxies need to > keep session state. > What other possibilities are there? The solution you choose will be based on why you care that this is a re-INVITE. I think that in almost all cases, if you really care, you will maintain session state. > I would go one step further, and at least discourage > people from > loose-routing _subsequent_ requests (e.g. > re-INVIVEs). I see no reason to do this. Loose routing is all about local policy. As long as the strict route is honored, it shouldn't matter what happens in subsequent requests. /sean __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 22 10:59:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27724 for ; Tue, 22 Jan 2002 10:59:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA14811 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 10:59:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13944; Tue, 22 Jan 2002 10:41:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13882 for ; Tue, 22 Jan 2002 10:41:31 -0500 (EST) Received: from web11603.mail.yahoo.com (web11603.mail.yahoo.com [216.136.172.55]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27102 for ; Tue, 22 Jan 2002 10:41:27 -0500 (EST) Message-ID: <20020122154129.59057.qmail@web11603.mail.yahoo.com> Received: from [208.237.135.12] by web11603.mail.yahoo.com via HTTP; Tue, 22 Jan 2002 07:41:29 PST Date: Tue, 22 Jan 2002 07:41:29 -0800 (PST) From: Sean Olson Subject: Re: [Sip] Issues with telephone-subscriber appearing in a SIP To: "Vijay K. Gurbani" , Jonathan Rosenberg Cc: Christer Holmberg , rsparks@dynamicsoft.com, james.yu@neustar.com, SIP WG List In-Reply-To: <3C4CA6F9.58BD32B4@lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > I think we need to consider the pros/cons of that. > I only vaguely > > remember the email discussion that led to the > conclusion to put them in > > the user part. Certainly, collision of params is > one part. Another part > > is URI comparison; it becomes harder with them as > params, since one > > element that doesn't understand tel would ignore > the params, whereas > > they would be needed for comparison of the tel URL > itself. Thus, > > equivalency would be different as a sip URL v. a > tel URL, which seems wrong. > > Namespace collision could be mitigated by the LNP > I-D (when it becomes a RFC) > defining a protected namespace for these parameters. This doesn't help. The potential collision stems from using the same parameter name in both the SIP URL and the "tel" portion of the user part. > > Regarding equivalency being different on a SIP URL > vs. a tel URL, isn't that > what we want? In other words, > sip:+1-202-533-1234;rn=+1-202-544-0000;npdi=yes@xxx.yyy.biz;user=phone > > and > tel:+1-202-533-1234;rn=+1-202-544-0000;npdi=yes > > will not be treated the same anyway since the scheme > (sip:, tel:) does not > match. The problem is that the same parameters would take on different meanings depending on whether they were present in a SIP vs. Tel Url. That is, they would mean something in the tel URL and possibly mean nothing in the SIP URL. > On a SIP URL containing a E.164 number, I do not see > any problems in URL comp- > arision if the parameters appear at the end (R-URI > parameters). That is, > given a SIP URL: > sip:+1-202-533-1234@xxx.yyy.biz;user=phone;rn=+1-202-544-0000;npdi=yes > > the normal URL matching rules would apply; i.e. the > scheme has to match, the > user part has to match, the domain has to match, and > the parameters have to > match. SIP entities that do not know anything about > the parameters "npdi" > and "rn" can still match the name of the parameter > ("npdi", "rn") and the > octets that appear as the value of these parameters. My original argument for having these parameters as part of the user part is that they really do reflect attributes of the "user" and not of the SIP URL as a whole. At least the original parameters did. With the new LNP stuff, this gets a little trickier. There is also an argument for allowing the tel: URI stuff to evolve independently of the SIP URL specification. (Admittedly this is weaker, but this is where the namespace collision stuff comes into play) > Regards, > > - vijay > -- > Vijay K. Gurbani > vkg@{lucent.com,research.bell-labs.com,acm.org} > Internet Software and eServices Group > Lucent Technologies/Bell Labs Innovations, 2000 > Lucent Lane, Rm 6G-440 > Naperville, Illinois 60566 Voice: +1 630 224 > 0216 Fax: +1 630 713 0184 > /sean ===== Sean Olson __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 22 11:32:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29063 for ; Tue, 22 Jan 2002 11:32:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19998 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 11:32:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16464; Tue, 22 Jan 2002 11:13:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16264 for ; Tue, 22 Jan 2002 11:13:29 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28384 for ; Tue, 22 Jan 2002 11:13:25 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA26317; Tue, 22 Jan 2002 11:09:34 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0MG9WJ1000274; Tue, 22 Jan 2002 11:09:32 -0500 (EST) Message-ID: <3C4D8EBC.5409704C@cs.columbia.edu> Date: Tue, 22 Jan 2002 11:09:32 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , Juha Heinanen , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C485371.4E2893A6@cs.columbia.edu> <3C4C4652.1060009@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > With the caveat that I believe this should apply NOT just for numbers, > but for any entered data which is not otherwise qualified. That is, if I > enter "bob", and the UA doesn't know what else to do with it (no match > in address book, etc.), it uses example.com. This mirrors my email > client behavior exactly. We should, I believe, formalize the notion of a 'home domain' in the spec, so that we can easily make such statements and so that configuration profiles know what this is. Maybe people will even use the same terminology and everybody knows what to put there... > > Now, I should also point out that this rule ONLY applies when the UA > doesn't have policy to specify otherwise. I see nothing wrong with > having a button that says "resolve this in my visited domain", or an > explicit policy at the UA which prefers tel URL. The point of this > requirement is to define behavior in the absence of any explicitly > defined policy. You can still have policies to support local resolution > of addresses if you want (and indeed, you do want that for things like 411). I suspect that some of this is probably better codified in a "implementation recommendations for SIP UA" document being written in the SIP Forum, rather than a protocol spec. I would see such recommendations as "here's something to think about - you can do something different, but be aware of the trade-offs". > > -Jonathan R. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 22 11:46:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29527 for ; Tue, 22 Jan 2002 11:46:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA20601 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 11:46:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18380; Tue, 22 Jan 2002 11:18:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18333 for ; Tue, 22 Jan 2002 11:18:14 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28718 for ; Tue, 22 Jan 2002 11:18:10 -0500 (EST) From: bernhard.honeisen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0MGIFt09137 for ; Tue, 22 Jan 2002 18:18:15 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jan 2002 18:18:12 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 22 Jan 2002 18:18:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Loose Routing draft Date: Tue, 22 Jan 2002 18:18:11 +0200 Message-ID: Thread-Topic: [Sip] Loose Routing draft Thread-Index: AcGjWYyvL7+jObsuRNakQeZxBCnXcAAA+paA To: , Cc: X-OriginalArrivalTime: 22 Jan 2002 16:18:12.0098 (UTC) FILETIME=[6348AE20:01C1A360] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA18334 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Sean! >-----Original Message----- >From: ext Sean Olson [mailto:seancolson@yahoo.com] >Sent: 22. January 2002 17:29 >To: Honeisen Bernhard (NET/Helsinki); sip@ietf.org >Cc: rsparks@dynamicsoft.com >Subject: RE: [Sip] Loose Routing draft > > > >> How can a proxy make the difference between an >> initial INVITE >> and a re-INVITE? >> I have a feeling, that checking the To tag is not >> the best solution. >> Neither it is a good solution, if proxies need to >> keep session state. >> What other possibilities are there? > >The solution you choose will be based on why >you care that this is a re-INVITE. I think that >in almost all cases, if you really care, you >will maintain session state. What about cases, where: - a proxy is dedicated to insert pre-loaded Route headers, and - only in initial request, and - doesn't want to keep session state Or is such a case unrealistic? I guess, we could find more examples, where we need this. >> I would go one step further, and at least discourage >> people from >> loose-routing _subsequent_ requests (e.g. >> re-INVIVEs). > >I see no reason to do this. Loose routing is all >about local policy. As long as the strict >route is honored, it shouldn't matter what happens >in subsequent requests. Especially in cases, where you some element keeps session state it should get also e.g. the BYE concerning this session, in order to release the resources. If a proxy before is allowed to just modify the Request-URI (which has been recorded earlier in Record-Route), it cannot be totally sure anymore. This is way, we cannot claim the loose-routing to be 100% backwards compatible, if such things are possible. I have the feeling, that we have to: 1) be able to distinguish whether a Route header has been preloaded or not e.g. we could introduce a new Route parameter, informing about "preloaded" 2) maybe even restrict the loose-routing in preloaded case so much, that we can ensure that every request passes the proxies, which had record-routed. If we make the difference between pre-loaded and not pre-loaded (instead of between first and sub-sequest requests), we still can have a (limited) loose routing possibility in subsequent requests. cheers Bernie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 22 12:09:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00751 for ; Tue, 22 Jan 2002 12:09:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA29324 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 12:09:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20225; Tue, 22 Jan 2002 11:41:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20195 for ; Tue, 22 Jan 2002 11:41:33 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29364 for ; Tue, 22 Jan 2002 11:41:29 -0500 (EST) From: bernhard.honeisen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0MGfYt19383 for ; Tue, 22 Jan 2002 18:41:34 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Jan 2002 18:41:30 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 22 Jan 2002 18:41:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 22 Jan 2002 18:41:13 +0200 Message-ID: Thread-Topic: Questions for Loose Route example Thread-Index: AcGjY4ZnbkKxhw9PEdatUABQi80jQw== To: Cc: X-OriginalArrivalTime: 22 Jan 2002 16:41:13.0543 (UTC) FILETIME=[9AB07570:01C1A363] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA20196 Subject: [Sip] Questions for Loose Route example Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Robert et al. I am referring to the email sent by RjS on Tue 15.01.2002 concerning the appending the intended destination at the end of the Route set. I still try to understand the loose route idea better. Let's make another example: A -> P1 ======= A want to send a request to B traversing P1 and P2 before B; i.e. A -> P1 -> P2 -> B R-URI: B@nwb.com; maddr=p1.serviceop.com ... Route: p2.tracing.com ... P1 -> P2 ======== P1 knows more about B and retargets the destination to B@xyz.com. The "incoming" Route goes to maddr. R-URI: B@xyz.com; maddr=p2.tracing.com ... (no Route) ... Record-Route: B@nwb.com; maddr=p1.serviceop.com ... P2 -> B ======= P2 strips maddr and routes to B. R-URI: B@xyz.com ... (no Route) ... Record-Route: B@xyz.com; maddr=p2.tracing.com, B@nwb.com; maddr=p1.serviceop.com ... --- Is this a typical example of how such a retargeting service should be performed? Are there other examples on how this could/should be done? In particular, I am interested, on how P1 should handle this situation. I think we should have a clear understanding on how this is done, before we can introduce this to the bis draft. Even an inclusion in some example section (or I/D) should be considered. Please comment/improve this example. cheers, Bernie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 22 13:52:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04679 for ; Tue, 22 Jan 2002 13:52:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA04345 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 13:52:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02386; Tue, 22 Jan 2002 13:13:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02355 for ; Tue, 22 Jan 2002 13:13:47 -0500 (EST) Received: from revere.sonusnet.com (mail.sonusnet.com [208.45.178.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02789 for ; Tue, 22 Jan 2002 13:13:45 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0MICUe07901; Tue, 22 Jan 2002 13:12:30 -0500 (EST) Received: from matt.verizon.net (Matt.sonusnet.com [10.128.130.67]) by sonusdc3.sonusnet.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DATJ4BXG; Tue, 22 Jan 2002 13:12:35 -0500 Message-Id: <5.1.0.14.2.20020122100957.022559d0@mail.verizon.net> X-Sender: res06gzk@mail.verizon.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 22 Jan 2002 10:12:08 -0800 To: Lei Liang , sip@ietf.org From: Matt Holdrege Subject: Re: [Sip] cooperate with Megaco? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org An MGC function is in part a protocol engine and can support and interwork many protocols such as SIP, MEGACO, H.323, LDAP, etc. But the development of each protocol is independent so we needn't concern ourselves with it in the SIP working group. And the interworking happens within the MGC function so that is out of scope here too. At 06:52 AM 1/22/2002, Lei Liang wrote: >Hi, guys, > I see in Megaco the MGC support SDP and SIP. but I don't know how >exactly it works. is there idea to handle this problem in SIP >consideraton? > I also wondered how SIP is translated to a PSTN handset. is there any >specification in the bis-05? > >thanks a lot. >lei > > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 22 15:10:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08645 for ; Tue, 22 Jan 2002 15:10:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09530 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 15:10:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07572; Tue, 22 Jan 2002 14:31:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07517 for ; Tue, 22 Jan 2002 14:31:47 -0500 (EST) Received: from NS1.US.PRSERV.NET ([64.180.246.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06866 for ; Tue, 22 Jan 2002 14:31:43 -0500 (EST) From: sydney@vkistudios.org Message-Id: <200201221931.OAA06866@ietf.org> Reply-To: seo@vkistudios.org To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 22 Jan 2002 11:35:17 -0800 Subject: [Sip] ADV: Professional Internet Marketing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Professional Internet Marketing, VKI Studios 1-866-733-8899
1-866-733-8899 

 

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 22 15:12:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08699 for ; Tue, 22 Jan 2002 15:12:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA09703 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 15:12:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08391; Tue, 22 Jan 2002 14:45:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08360 for ; Tue, 22 Jan 2002 14:45:07 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07646 for ; Tue, 22 Jan 2002 14:45:03 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0MJiWS00224; Tue, 22 Jan 2002 14:44:33 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0MJiUT26728; Tue, 22 Jan 2002 14:44:30 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jan 2002 14:44:30 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75401015697@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "Henning G. Schulzrinne" , Jonathan Rosenberg Cc: Dean Willis , Juha Heinanen , sip@ietf.org Subject: RE: [Sip] Open Issue #366: sip v. tel URL Date: Tue, 22 Jan 2002 14:44:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A37D.33C62E30" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A37D.33C62E30 Content-Type: text/plain; charset="ISO-8859-1" see below > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, January 22, 2002 11:10 AM > To: Jonathan Rosenberg > Cc: Dean Willis; Juha Heinanen; sip@ietf.org > Subject: Re: [Sip] Open Issue #366: sip v. tel URL > > > Jonathan Rosenberg wrote: > > > > I suspect that some of this is probably better codified in a > "implementation recommendations for SIP UA" document being written in > the SIP Forum, rather than a protocol spec. I would see such > recommendations as "here's something to think about - you can do > something different, but be aware of the trade-offs". > > > > > -Jonathan R. agreed, it seems that this is the right thing to do abbie ------_=_NextPart_001_01C1A37D.33C62E30 Content-Type: text/html; charset="ISO-8859-1" RE: [Sip] Open Issue #366: sip v. tel URL

see below

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, January 22, 2002 11:10 AM
> To: Jonathan Rosenberg
> Cc: Dean Willis; Juha Heinanen; sip@ietf.org
> Subject: Re: [Sip] Open Issue #366: sip v. tel URL
>
>
> Jonathan Rosenberg wrote:
> >
>
> I suspect that some of this is probably better codified in a
> "implementation recommendations for SIP UA" document being written in
> the SIP Forum, rather than a protocol spec. I would see such
> recommendations as "here's something to think about - you can do
> something different, but be aware of the trade-offs".
>
> >
> > -Jonathan R.

agreed, it seems that this is the right thing to do

abbie

------_=_NextPart_001_01C1A37D.33C62E30-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 22 16:39:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11593 for ; Tue, 22 Jan 2002 16:39:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA13781 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 16:39:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12212; Tue, 22 Jan 2002 15:57:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12180 for ; Tue, 22 Jan 2002 15:57:02 -0500 (EST) Received: from valen.greycouncil.com (bdsl.66.12.12.131.gte.net [66.12.12.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10023 for ; Tue, 22 Jan 2002 15:56:56 -0500 (EST) Received: from there (valen.greycouncil.com [127.0.0.1]) by valen.greycouncil.com (8.11.6/8.11.6) with SMTP id g0MKutB07305; Tue, 22 Jan 2002 14:56:55 -0600 Message-Id: <200201222056.g0MKutB07305@valen.greycouncil.com> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: "Henning G. Schulzrinne" Subject: Re: [Sip] Open Issue #366: sip v. tel URL Date: Tue, 22 Jan 2002 14:56:54 -0600 X-Mailer: KMail [version 1.3.2] References: <3C34C2AD.3000301@dynamicsoft.com> <005501c1a040$602086a0$0a64a8c0@flak> <3C485371.4E2893A6@cs.columbia.edu> In-Reply-To: <3C485371.4E2893A6@cs.columbia.edu> Cc: sip@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Dial "7" to reach housekeeping . . . It's the old local-versus-home services question. I would argue that if I really want home services, I should explicitly qualify the URL to indicate that I wanted it evaluated only in my home domain. An unqualified URL should get evaluated the first place that feels capabale of evaluating it . . . This makes things like 911, 411, and 112 services much easier to deal with. -- Dean On Friday 18 January 2002 10:55 am, you wrote: > Dean Willis wrote: > > No, because quite probably if you're visiting someone else's > > corporate SIP phone, the gateway that will (perhaps MUST) be used > > for PSTN termination is the local gateway, not the one back in your > > home domain. > > Why is that? In most cases, I would certainly prefer to use my own > phone service, rather than the hotel phone service, for example. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 22 16:49:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11939 for ; Tue, 22 Jan 2002 16:48:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA14083 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 16:49:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12289; Tue, 22 Jan 2002 15:58:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12257 for ; Tue, 22 Jan 2002 15:58:44 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10063 for ; Tue, 22 Jan 2002 15:58:35 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 18EE91E2CB for ; Tue, 22 Jan 2002 15:58:18 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA19890; Tue, 22 Jan 2002 15:58:13 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id PAA44216; Tue, 22 Jan 2002 15:59:01 -0500 (EST) Date: Tue, 22 Jan 2002 15:59:01 -0500 (EST) Message-Id: <200201222059.PAA44216@fish.research.att.com> To: sip@ietf.org Subject: Re: [Sip] Comments on "unify" draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan wrote: > > In general, it would be helpful to get general feedback of the form > "seems like the right direction". Particularly, the main thing I need > feedback on ASAP is the proposal to pretty much keep this all out of > bis. The only thing in bis would be some generalized statement of when > you can see offers and answers, so that we can separate the > EM/manyfolks/herfp solutions from bis. Granted, this stuff still needs > to be on the fast track for 3g, but I want to get it separated from bis. > First, I definitely agree this aspect should be decided quickly. I may be in the minority, but I think that a problem in 2543 should be fixed in the next version of the RFC, and that HERFP qualifies as a bug in 2543. It seems wrong to have a "supported:" tag defined for a fix for a bug. The main argument against this that I see is one of backwards compatability. But everyone seems to agree that a UA or proxy written to conform to 2543 is nearly useless - so the question seems to be one of backwards compatability to what? Do we really need to maintain backwards comatability to a I-D, defined as only a "Work in Progress"? With the definition of Route and Record-Route in bis, we've already given up backwards compatability with a pure-2543 proxy, and a fix for HERFP does not make the situation any worse. Second point is that 2543 already allows 1-of-N codec negotiation through the use of a 3-way handshake (SDP in INVITE, subset in 200, new SDP in ACK). So the statement that the 3-way handshake is not backwards compatible is only with bis, not 2543, since the restriction to offer/answer appears only in bis. Again this seems to be a problem in bis, and should be fixed in bis. Offer/Counter-Offer/Answer is a much cleaner solution than a two-stage invite (although as an author of the original two-stage invite proposal, draft-dcsgroup-mmusic-resource-00, June 1999, it is interesting that it has returned; all that is missing is the No-Ring header in the first invite!). The early media, and handling of multiple early media streams, and resource reservation before alerting, all seem to be more "extensions" than "bugs", so I'd agree with them being in separate drafts. But if COMET (or UPDATE) is defined in bis, these drafts would be short. Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 22 19:34:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15441 for ; Tue, 22 Jan 2002 19:34:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA19916 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 19:34:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18147; Tue, 22 Jan 2002 18:32:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18113 for ; Tue, 22 Jan 2002 18:32:10 -0500 (EST) Received: from radvpost.us.radvision.com ([38.150.216.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14392 for ; Tue, 22 Jan 2002 18:32:06 -0500 (EST) Received: by RADVPOST with Internet Mail Service (5.5.2650.21) id ; Tue, 22 Jan 2002 18:30:18 -0500 Message-ID: <0D5BBF5D638DD4119E3400508BD949459ED801@RADVPOST> From: Orit Levin To: "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] Very ROUGH thinking on DNS/SRV usage Date: Tue, 22 Jan 2002 18:30:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan, The SRV records can be (and have been) used to retrieve and determine supported transports (using the "Proto" field). What is the motivation for adding the NAPTR based domain-to-transport (pre-) lookup? It adds additional lookup time and doesn't seem to correctly interpret NAPTR syntax and semantics. Was it based on some specific requirements or/and experts' inputs? Orit. BTW: When I wrote an analogous specification for H.323 (i.e. Annex O), I have come to the same conclusion that having "port" in URL (INCLUDING the well-known values) implies having address records at the DOMAIN of the URL. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, December 24, 2001 3:29 PM To: sip@ietf.org Subject: [Sip] Very ROUGH thinking on DNS/SRV usage Folks, I've cobbled together an update to the SRV usages document. It will live as a separate specification, outside of bis. The update is based on various comments from IESG and DNS experts. It is still in a state of flux, so please don't go off and implement it. Comments are welcome, of course. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-sip-srv-03.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 22 19:35:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15498 for ; Tue, 22 Jan 2002 19:35:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA20003 for sip-archive@odin.ietf.org; Tue, 22 Jan 2002 19:35:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18608; Tue, 22 Jan 2002 18:59:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18576 for ; Tue, 22 Jan 2002 18:59:28 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14795 for ; Tue, 22 Jan 2002 18:59:25 -0500 (EST) Received: from joel ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g0MNxPQ90512; Tue, 22 Jan 2002 18:59:25 -0500 (EST) Reply-To: From: "Joel Rosenfield" To: Cc: Date: Tue, 22 Jan 2002 19:03:01 -0500 Message-ID: <000501c1a3a1$545cbaf0$3801a8c0@joel> 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 V5.50.4133.2400 Content-Transfer-Encoding: 7bit Subject: [Sip] Syntax questions regarding draft-ietf-sip-privacy-03.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I have a few questions/concerns about the description of the new header RPID-Privacy: 1) Section 5.2 on page 11 defines the syntax of the header as follows: RPID-Privacy = "RPID-Privacy" ":" 1*(";" rpid-privacy-token) ; rpi-privacy MUST be present rpid-privacy-token = rpi-pty-type | rpi-id-type | rpi-privacy This would seem to infer that the first token should be preceded by a semi-colon. 2) Later on page 12, the following example is given: RPID-Privacy: rpi-privacy=full;party=calling;id-type=subscriber Note that there is no initial semi-colon. Furthermore, the definition of rpi-privacy in Seciont 5.1, page 9 describes the following syntax: rpi-privacy = "privacy" "=" ("full" | "name" | "uri" | "off" | token ) [ "-" ( "network" | token ) ] ) Based upon these issues, should this example be written as follows? RPID-Privacy: ;privacy=full;party=calling;id-type=subscriber 3) Finally, Section 7.1 on page 23 contains the following example: RPID-Privacy: full _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 23 02:36:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02942 for ; Wed, 23 Jan 2002 02:36:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA13199 for sip-archive@odin.ietf.org; Wed, 23 Jan 2002 02:36:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11837; Wed, 23 Jan 2002 02:08:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA11806 for ; Wed, 23 Jan 2002 02:08:54 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02276 for ; Wed, 23 Jan 2002 02:08:52 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0N76Rm2015436; Wed, 23 Jan 2002 02:06:28 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 02:08:18 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9C2@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'bernhard.honeisen@nokia.com'" , Robert Sparks Cc: sip@ietf.org Subject: RE: [Sip] Questions for Loose Route example Date: Wed, 23 Jan 2002 02:08:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org What you have below would is a reasonable scenario. Note that in the initial request (what you show) the maddr parameters in the request-URI are not necessary. A can send the message to P1 with a R-URI of B@nwb.com. In fact, while you are discovering the path to the destination, using maddr as you have below can break if at some point a URI with a non-default transport or port is introduced. (Say P1 found that the request should goto B@xyz.com:6000). I'll be posting more on this shortly. In subsequent requests each element record-routing (and the last hop using a Contact) can specify the appropriate transport/port values for that hop, so maddrs appearing in those request URIs isn't a problem. RjS > -----Original Message----- > From: bernhard.honeisen@nokia.com [mailto:bernhard.honeisen@nokia.com] > Sent: Tuesday, January 22, 2002 10:41 AM > To: rsparks@dynamicsoft.com > Cc: sip@ietf.org > Subject: [Sip] Questions for Loose Route example > > > Hi Robert et al. > > I am referring to the email sent by RjS on Tue 15.01.2002 > concerning the appending the intended destination at the > end of the Route set. > > I still try to understand the loose route idea better. > Let's make another example: > > > A -> P1 > ======= > > A want to send a request to B traversing > P1 and P2 before B; > i.e. A -> P1 -> P2 -> B > > R-URI: B@nwb.com; maddr=p1.serviceop.com Its not necessary for the maddr to be in this request-URI - A can just send the request to P1. In fact, the maddr really shouldn't be there for this case. > ... > Route: p2.tracing.com > ... > > P1 -> P2 > ======== > > P1 knows more about B and retargets the destination to > B@xyz.com. The "incoming" Route goes to maddr. > > R-URI: B@xyz.com; maddr=p2.tracing.com > ... > (no Route) > ... > Record-Route: B@nwb.com; maddr=p1.serviceop.com > ... > > P2 -> B > ======= > > P2 strips maddr and routes to B. > > R-URI: B@xyz.com > ... > (no Route) > ... > Record-Route: B@xyz.com; maddr=p2.tracing.com, > B@nwb.com; maddr=p1.serviceop.com > ... > > --- > > Is this a typical example of how such a retargeting service > should be performed? Are there other examples on how this > could/should be done? > In particular, I am interested, on how P1 should handle > this situation. > > I think we should have a clear understanding on how > this is done, before we can introduce this to the bis > draft. Even an inclusion in some example section > (or I/D) should be considered. > > Please comment/improve this example. > > cheers, > Bernie _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 23 10:52:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13404 for ; Wed, 23 Jan 2002 10:52:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01356 for sip-archive@odin.ietf.org; Wed, 23 Jan 2002 10:52:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29808; Wed, 23 Jan 2002 10:13:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29777 for ; Wed, 23 Jan 2002 10:13:30 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11802 for ; Wed, 23 Jan 2002 10:13:28 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0NFCKU23667; Wed, 23 Jan 2002 10:12:20 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA19849; Wed, 23 Jan 2002 09:12:18 -0600 (CST) Message-ID: <3C4ED2D0.2F9952B6@lucent.com> Date: Wed, 23 Jan 2002 09:12:16 -0600 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org CC: wtm@research.att.com, Jonathan Rosenberg Subject: Re: [Sip] Comments on "unify" draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > In general, it would be helpful to get general feedback of the form > "seems like the right direction". [...] William Marshall wrote: > I may be in the minority, but I think that a problem in 2543 should > be fixed in the next version of the RFC, and that HERFP qualifies > as a bug in 2543. It seems wrong to have a "supported:" tag defined > for a fix for a bug. For whatever it is worth, I agree with Bill here. We should fix the HERFP problem in the bis. Solving HERFP through an extension (which almost everyone will need to implement for a production grade system) is probably taking the easy way out. > The early media, and handling of multiple early media streams, and > resource reservation before alerting, all seem to be more "extensions" > than "bugs", so I'd agree with them being in separate drafts. But if > COMET (or UPDATE) is defined in bis, these drafts would be short. If the unify I-D is accepted, I really think that COMET (or UPDATE, or whatever method name we choose) should be part of the bis. I understand we do not want to delay the -06bis any longer, but if the unify I-D solves these problems, then the solution belongs in the RFC, not as an extension. Just my $0.02. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 23 13:24:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19377 for ; Wed, 23 Jan 2002 13:24:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09854 for sip-archive@odin.ietf.org; Wed, 23 Jan 2002 13:24:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08081; Wed, 23 Jan 2002 12:56:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08050 for ; Wed, 23 Jan 2002 12:56:52 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18438 for ; Wed, 23 Jan 2002 12:56:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0NHsVm2018661 for ; Wed, 23 Jan 2002 12:54:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 12:56:21 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9CC@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Wed, 23 Jan 2002 12:56:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #268 : port number and maddr Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This open issue has not been directly addressed on the list, but it has been touched on in several threads over the last few months. It has some impact on the looseroute proposal. Issue: What do the transport and port paramters on a SIP URI mean when an maddr parameter is present? Do they refer to the next hop or to the element ultimately responsible for the resource? Discussion: The maddr parameter has been used in several places to cause a request to be delivered to an address other than what would normally be derived from processing the remainder of a URI (such as the hostpart). For instance: UAC 1.2.3.4 foo.com | INVITE sip:a@foo.com;maddr=1.2.3.4 |-------------->| | | |INVITE sip:a@foo.com | |----------->| What does it mean when the first URI contains a port or transport parameter? For example: UAC 1.2.3.4 foo.com | INVITE sip:a@foo.com:6666;transport=tls;maddr=1.2.3.4 |-------------->| | What do the parameters mean to 1.2.3.4? Do they describe a port and transport to be reached at 1.2.3.4 or at foo.com? Obviously, they can't describe both. To be consistent with the historic mechanisms for determining where to send requests, and the procedures documented in sip-srv, they must be interpreted as describing how to reach 1.2.3.4. The penalty is that you can't then use maddr to cause a request to be routed through a proxy to a destination with a non-default port or transport. This isn't pretty, but it also isn't as limiting as it might seem at first. Almost everywhere maddr is currently being used, it is provided by the element responsible for the address it specifies (record-route for example). That element can also specify alternate ports and transports. Loose-routing elements don't need it - they just send the message to the address:port using the transport their policy dictates. They can also fully specify the address:port:transport of more than one place to visit by pushing Route header values. The only problem we have is that this interacts badly with the algorithm proposed in the looseroute draft for making the topmost Route header and the Request-URI sufficiently different to avoid inducing a loop-detection if the next hop just happens to be a strict-routing loop-detector. I'll be posting a discussion of that problem and an alternate solution shortly. Proposed Resolution: If a port or transport parameter is specified in a URL that contains an maddr parameter, the port and transport apply to the address indicated by the maddr parameter value. So, the flow above would continue UAC 1.2.3.4 foo.com | INVITE sip:a@foo.com:6666;transport=tls;maddr=1.2.3.4 |-------------->| | | | INVITE sip:a@foo.com | |----------->| assuming 1.2.3.4 received the message over tls at port 6666. If 1.2.3.4 recieved the message on some other port or using some other transport, it would forward the message to port 6666 at 1.2.3.4 over tls. I am documenting this in bis now. Please comment quickly. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 23 13:48:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20298 for ; Wed, 23 Jan 2002 13:48:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11171 for sip-archive@odin.ietf.org; Wed, 23 Jan 2002 13:48:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09670; Wed, 23 Jan 2002 13:19:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09639 for ; Wed, 23 Jan 2002 13:19:39 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19213 for ; Wed, 23 Jan 2002 13:19:36 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0NIJZIB011005; Wed, 23 Jan 2002 19:19:35 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0NIJYr6001236; Wed, 23 Jan 2002 20:19:35 +0200 (EET) Message-ID: <3C4EFEB6.23E0D662@lmf.ericsson.se> Date: Wed, 23 Jan 2002 20:19:34 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: sip@ietf.org Subject: Re: [Sip] problem with sip resonse code mapping to isup References: <15437.30788.503087.167965@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Juha, I think this question is a little related to one I had about the loose route proposal. My question then was: what does a proxy return if it receives an INVITE request with a pre-loaded route, and for whatever reason it is not able, or is not allowed to forward the request to that proxy. For most cases there are response codes available. But, if the following server is temporary "out of reach" I am not sure there were an exact code to use, but I think 403 was "as close as possible". Regards, Christer Holmberg Ericsson Finland Juha Heinanen wrote: > > if i try to call from pstn to a sip phone that is not currently > registered, the home proxy of the phone returns "404 not found". > according to draft-ietf-sipping-isup-00.txt the sip/isup gw then maps > that to "1 Unallocated number". > > i think this is plain wrong, because surely the number has been > allocated to the sip phone. the phone just happens to be off-line. in > finland pstn turns "1 Unallocated number" into a voice reply that goes > something like "the number doesn't exist, please check the number and > try again". from that the called gets the wrong impression that he has > got a wrong number. > > if i call to a cell phone that happens to be offline, i get from pstn a > message that goes something like "the number you tried to call is not > currently reachable, please try again later". i believe this is > generated from "18 No user responding". > > i would like to get this same announcement if i call a sip phone whose > number is not currently registered, but which the proxy knows exists in > its domain. according to the table in draft-ietf-sipping-isup-00.txt, i > can get "18 No user responding" if the proxy would return "480 > Temporarily unavailable". this however, is not possible according to > bis-05: > > 23.4.16 480 Temporarily Unavailable The callees end system was > contacted successfully but the callee is currently unavailable > (e.g., not logged in, logged in in such a manner as to > preclude communication with the callee or activated the do not > disturb feature). > > i.e., only the phone, not the proxy, can return such a message, but > obviously in this case it can't because proxy doesn't know where the > phone is and thus can't forward the invite to it. > > clearly something needs to be done in order to resolve this issue. i'll > include also the sip list, since it would be possible to do the fix in > either document. my initial feeling is that we would need a new error > response "4xx Offline", alternatively we need to change the wording of > 404, because now 404 should be returned if the "user doesn't exist", > which to very ambiguous to me. > > -- juha > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 23 14:03:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20841 for ; Wed, 23 Jan 2002 14:03:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA12411 for sip-archive@odin.ietf.org; Wed, 23 Jan 2002 14:03:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10669; Wed, 23 Jan 2002 13:38:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10638 for ; Wed, 23 Jan 2002 13:38:56 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19814 for ; Wed, 23 Jan 2002 13:38:53 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0NIcrio032177; Wed, 23 Jan 2002 20:38:53 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15439.829.840115.443005@harjus.eng.song.fi> Date: Wed, 23 Jan 2002 20:38:53 +0200 To: Christer Holmberg Cc: sip@ietf.org Subject: Re: [Sip] problem with sip resonse code mapping to isup In-Reply-To: <3C4EFEB6.23E0D662@lmf.ericsson.se> References: <15437.30788.503087.167965@harjus.eng.song.fi> <3C4EFEB6.23E0D662@lmf.ericsson.se> X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit may be "404 not found" is ok for the case when the called user is "offline", but definitely it is not ok to map that to "1 unallocated number". as i said, the sip spec could be a bit clearer on what the semantics of "not found" are. if "404 not found" is to be used also in the case when the proxy knows that the called user exists, but currently has no active registration, then correct isup mapping would be "18 no user responding". the only sip result code that i think could be mapped to "1 unallocated number" is "604 does not exist anywhere", which is not even mentioned in the table of draft-ietf-sipping-isup-00.txt. i'm wondering what has happened to the authors of draft-ietf-sipping-isup-00.txt, since noone has showed up to defend their table. may be they are "410 gone" :-). -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 23 16:05:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25379 for ; Wed, 23 Jan 2002 16:05:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA17883 for sip-archive@odin.ietf.org; Wed, 23 Jan 2002 16:05:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16490; Wed, 23 Jan 2002 15:34:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16430 for ; Wed, 23 Jan 2002 15:34:10 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24275; Wed, 23 Jan 2002 15:34:06 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0NKXUS14935; Wed, 23 Jan 2002 14:33:30 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g0NKXUM04279; Wed, 23 Jan 2002 14:33:30 -0600 (CST) Received: from lmf.ericsson.se (rmt160131.am.ericsson.se [138.85.160.131]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA09301; Wed, 23 Jan 2002 14:33:26 -0600 (CST) Message-ID: <3C4F2506.47ED8FD1@lmf.ericsson.se> Date: Wed, 23 Jan 2002 23:03:02 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: sipping@ietf.org, sip@ietf.org, Jonathan Rosemberg , "Christer Holmberg (LMF)" References: <15437.30788.503087.167965@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] problem with sip resonse code mapping to isup Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Juha, > i'm wondering what has happened to the authors of > draft-ietf-sipping-isup-00.txt, since noone has showed up to defend > their table. may be they are "410 gone" :-). We are pretty busy finishing bis-06. That's why we had not answered your mail before. Anyway, if you send the mail to the mailing list and cc us as well you will get faster responses. The definition of 480 Temporarily unvailable says: "This status is also returned by a redirect server that recognizes the user identified by the Request-URI but does not currently have a valid forwarding location for that user." We will change "redirect server" by "redirect or proxy server" in bis-06. With this change, your example does not work because your SIP server is returning 404 instead of 480. If it returns 480 the tables in the mapping draft work fine. Thanks, Gonzalo Juha Heinanen wrote: > > if i try to call from pstn to a sip phone that is not currently > registered, the home proxy of the phone returns "404 not found". > according to draft-ietf-sipping-isup-00.txt the sip/isup gw then maps > that to "1 Unallocated number". > > i think this is plain wrong, because surely the number has been > allocated to the sip phone. the phone just happens to be off-line. in > finland pstn turns "1 Unallocated number" into a voice reply that goes > something like "the number doesn't exist, please check the number and > try again". from that the called gets the wrong impression that he has > got a wrong number. > > if i call to a cell phone that happens to be offline, i get from pstn a > message that goes something like "the number you tried to call is not > currently reachable, please try again later". i believe this is > generated from "18 No user responding". > > i would like to get this same announcement if i call a sip phone whose > number is not currently registered, but which the proxy knows exists in > its domain. according to the table in draft-ietf-sipping-isup-00.txt, i > can get "18 No user responding" if the proxy would return "480 > Temporarily unavailable". this however, is not possible according to > bis-05: > > 23.4.16 480 Temporarily Unavailable The callees end system was > contacted successfully but the callee is currently unavailable > (e.g., not logged in, logged in in such a manner as to > preclude communication with the callee or activated the do not > disturb feature). > > i.e., only the phone, not the proxy, can return such a message, but > obviously in this case it can't because proxy doesn't know where the > phone is and thus can't forward the invite to it. > > clearly something needs to be done in order to resolve this issue. i'll > include also the sip list, since it would be possible to do the fix in > either document. my initial feeling is that we would need a new error > response "4xx Offline", alternatively we need to change the wording of > 404, because now 404 should be returned if the "user doesn't exist", > which to very ambiguous to me. > > -- juha > > _______________________________________________ > 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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 23 16:16:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25691 for ; Wed, 23 Jan 2002 16:15:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA18066 for sip-archive@odin.ietf.org; Wed, 23 Jan 2002 16:15:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17044; Wed, 23 Jan 2002 15:50:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17013 for ; Wed, 23 Jan 2002 15:50:27 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24915 for ; Wed, 23 Jan 2002 15:50:24 -0500 (EST) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0NKns606674; Wed, 23 Jan 2002 15:49:54 -0500 (EST) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA26099; Wed, 23 Jan 2002 14:49:52 -0600 (CST) Message-ID: <3C4F21F1.3CDB8099@lucent.com> Date: Wed, 23 Jan 2002 14:49:53 -0600 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #268 : port number and maddr References: <9BF66EBF6BEFD942915B4D4D45C051F338E9CC@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Response inline... Robert Sparks wrote: > > This open issue has not been directly addressed on the list, > but it has been touched on in several threads over the last > few months. It has some impact on the looseroute proposal. > > Issue: What do the transport and port paramters on a SIP URI > mean when an maddr parameter is present? Do they refer > to the next hop or to the element ultimately responsible > for the resource? [...] > Proposed Resolution: > > If a port or transport parameter is specified in a URL that contains > an maddr parameter, the port and transport apply to the address > indicated by the maddr parameter value. This is the existing behavior, if I am not mistaken. > So, the flow above would continue > UAC 1.2.3.4 foo.com > | INVITE sip:a@foo.com:6666;transport=tls;maddr=1.2.3.4 > |-------------->| | > | | INVITE sip:a@foo.com > | |----------->| > > assuming 1.2.3.4 received the message over tls at port 6666. > If 1.2.3.4 recieved the message on some other port or using > some other transport, it would forward the message to port > 6666 at 1.2.3.4 over tls. > > I am documenting this in bis now. Please comment quickly. I have no problems with the resolution. However, would something like this be entertained: INVITE sip:a@foo.com:7777;maddr=1.2.3.4:9999:tls In other words, the maddr will have 2 optional values, separated by :. Here, port 7777 affects foo.com and port 9999 affects 1.2.3.4. While this has the nice property that all factors that affect maddr are in the maddr parameter, the biggest disadvantage is that it is NOT backward compatible. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 23 17:40:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28351 for ; Wed, 23 Jan 2002 17:40:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA21514 for sip-archive@odin.ietf.org; Wed, 23 Jan 2002 17:40:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20675; Wed, 23 Jan 2002 17:19:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20646 for ; Wed, 23 Jan 2002 17:19:44 -0500 (EST) Received: from imo-d01.mx.aol.com (imo-d01.mx.aol.com [205.188.157.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27848 for ; Wed, 23 Jan 2002 17:19:42 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-d01.mx.aol.com (mail_out_v31_r1.26.) id l.141.8518925 (4216) for ; Wed, 23 Jan 2002 17:19:04 -0500 (EST) Message-ID: <141.8518925.298090d7@aol.com> Date: Wed, 23 Jan 2002 17:19:03 EST To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Content-Transfer-Encoding: 7bit Subject: [Sip] Comments on Resource Priority Header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I have the following comments on draft-polk-sip-resource-01: General: It is suggested that statements regarding the use of the header (i.e., definition of a service which uses the header) should be deleted from this draft. Some of these procedures may be different for various situations or services or depend on network policies, so this document should not state MUST or SHOULD NOT provisions for these procedures. Section 3: 2nd paragraph: Is it necessary for the priority values to be assigned by IANA? After a namespace is registered, would it be sufficient for the "owner" of that namespace to assign priority values without IANA registration? 3rd paragraph: "As a response header ..." - It is unknown where this function would be used in the required procedures. Current requirements are that the priority level is specified by the caller and the called party has no option to change or reject the level. It is okay to identity that this header may optionally be included in the response, but it should not state its actual meaning (procedures). The following paragraph is suggested: "The resource priority header MAY be included in a response, either with the same or different value than the one contained in the request. The meaning of this response value depends on the application and details are beyond the scope of this document.." 4th paragraph: "If the header field is missing ..." should be deleted, since this relates to the procedures for use rather than the definition of the header itself. In some networks, this could be cause for rejecting the call rather than defaulting to a specific value. 5th paragraph: "The values are adopted from RFC 791 ..." and following 2 paragraphs should be moved to go with the description of the specific levels for the "dsn". It would probably be useful to include all information regarding the values for the Defense Switched Network in an Annex, with a reference to it in the IANA considerations for the initial registration. (See final comment.) 8th paragraph "Proxies MAY downgrade ... SHOULD NOT reject requests..." - This should be deleted or changed since the procedures to be followed depend on the network policies and the service being provided. For example, in the equivalent ISDN standards today, the call is released (rejected) in this case. The following paragraph is suggested: "Proxies MAY downgrade the Resource-Priority of or reject unauthenticated requests. Details are specific to each administrative domain and beyond the scope of this document." 4. IANA Why is a restriction needed that an existing list not be extended? If the dsn wishes to later add a new level below "Routine", it should be allowed to do so. Other: Since one of the uses is "carrying information from one multi-level domain in the telephone network, e.g., using the facilities of Q.735.3, to another, without the SIP proxies themselves inspecting the header field", it would be useful and efficient to preassign a single standard "namespace" of something like "PSTN" with values of "0", "1", "2", "3", and "4" to directly carry the values defined in Q.735.3. Otherwise, various networks in different countries may define different namespaces and values to indicate their local meanings of the currently defined 5 levels (possibly in their local language). This would make interworking difficult. If this is added, it is suggested that it also go in an Annex along with the description of the dsn values. That Annex would be as follows: Annex A Initial Registration of Namespace and Priority Values IANA is requested to register the following two namespaces and their associate priority values: 1. PSTN/ISDN equivalents In order to support carrying information between Q.735.3 (or equivalent) PSTN/ISDN entities without intervening interpretation by SIP proxies and to avoid the necessity of the gateway performing unnecessary interpretation or interworking between different networks, the following common, standard definition is made: Namespace = "pstn" (Public Switched Telephone Network) Priority Values = "0", "1", "2", "3", and "4", where "0" is the highest, etc. 2. Defense Switched Network (US Military) The Defense Switched Network (dsn) of the US military, as well as those of many other counties, uses a definition of priority levels that is a subset of those defined in RFC 791 [4]. In support of these applications, the following definition is made: Namespace = "dsn" (Defense Switched Network) Priority values = "critic-ecp", "flash-override", "flash", "immediate", "priority", "routine" The values are prioritized in the order "critic-ecp" (highest), "flash-override", "flash", "immediate", "priority" and "routine" (lowest). The value "critic-ecp" stands for "Critical and Emergency Call Processing" [4]. This value SHOULD only be used for authorized emergency communications, for example in the United States Government Emergency Telecommunications Service (GETS) [5], the United Kingdom Government Telephone Preference Scheme (GTPS) and similar government emergency preparedness or reactionary implementations elsewhere. Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 23 21:46:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02585 for ; Wed, 23 Jan 2002 21:46:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA28201 for sip-archive@odin.ietf.org; Wed, 23 Jan 2002 21:46:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27577; Wed, 23 Jan 2002 21:23:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27544 for ; Wed, 23 Jan 2002 21:23:06 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01454 for ; Wed, 23 Jan 2002 21:23:03 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA12947; Wed, 23 Jan 2002 18:22:23 -0800 (PST) Message-ID: <3C4F6FF3.185D655C@cisco.com> Date: Wed, 23 Jan 2002 21:22:43 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: joel@broadsoft.com CC: wtm@research.att.com, sip@ietf.org Subject: Re: [Sip] Syntax questions regarding draft-ietf-sip-privacy-03.txt References: <000501c1a3a1$545cbaf0$3801a8c0@joel> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Joel Rosenfield wrote: > I have a few questions/concerns about the description of the new header > RPID-Privacy: > > 1) Section 5.2 on page 11 defines the syntax of the header as follows: > > RPID-Privacy = "RPID-Privacy" ":" 1*(";" rpid-privacy-token) > ; rpi-privacy MUST be present > > rpid-privacy-token = rpi-pty-type | rpi-id-type | rpi-privacy > > This would seem to infer that the first token should be preceded by a > semi-colon. > Oops - I will correct this to not require the initial semi-colon. > > 2) Later on page 12, the following example is given: > > RPID-Privacy: rpi-privacy=full;party=calling;id-type=subscriber > > Note that there is no initial semi-colon. Furthermore, the definition of > rpi-privacy in Seciont 5.1, page 9 describes the following syntax: > > rpi-privacy = "privacy" "=" > > ("full" | "name" | "uri" | "off" | token ) > [ "-" ( "network" | token ) ] ) > > Based upon these issues, should this example be written as follows? > > RPID-Privacy: ;privacy=full;party=calling;id-type=subscriber Yes (except for the initial semi-colon). > > > 3) Finally, Section 7.1 on page 23 contains the following example: > > RPID-Privacy: full > Right - that one is correct. Thanks for the comments. -- Flemming > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 02:07:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16537 for ; Thu, 24 Jan 2002 02:07:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA15248 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 02:07:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14273; Thu, 24 Jan 2002 01:39:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14244 for ; Thu, 24 Jan 2002 01:39:47 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08032 for ; Thu, 24 Jan 2002 01:39:45 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0O6djw18884 for ; Thu, 24 Jan 2002 07:39:45 +0100 (MET) Received: from lmf.ericsson.se (lmf04630pc.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0O6dir6001941 for ; Thu, 24 Jan 2002 08:39:44 +0200 (EET) Message-ID: <3C4FAC2F.542DD7BB@lmf.ericsson.se> Date: Thu, 24 Jan 2002 08:39:43 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] 1-of-N codecs + inband DTMF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, This is not directly related to the unify draft, but to the "1-of-N codecs" mechanism in general. Assume that we want to also use inband DTMF, according to RFC 2833. So, since the DTMF from a SDP point of view now is a separate codec, in this case the final codec selection would be 2-of-N codecs, because I don't think anyone wants to send a re-INVITE everytime an inband DTMF is to be sent... Do you think this special case should be mentioned somewhere in the text? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 02:56:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17160 for ; Thu, 24 Jan 2002 02:56:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA16486 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 02:56:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15979; Thu, 24 Jan 2002 02:30:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15949 for ; Thu, 24 Jan 2002 02:30:50 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16864 for ; Thu, 24 Jan 2002 02:30:47 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0O7UZw08303; Thu, 24 Jan 2002 08:30:35 +0100 (MET) Received: from lmf.ericsson.se (lmf04630pc.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0O7UYr6004944; Thu, 24 Jan 2002 09:30:34 +0200 (EET) Message-ID: <3C4FB818.3069EB9B@lmf.ericsson.se> Date: Thu, 24 Jan 2002 09:30:32 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mukesh R Shah CC: sip@ietf.org Subject: Re: [Sip] Regarding MIME content handling References: <007201c1a4a9$108dc7c0$3c116f0a@HJNTNI108931> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, MIME contents are "handled" in SIP like anywhere else. Please have a look at the MIME RFCs. In draft-ietf-sip-isup-mime-10.txt you'll find an example how MIME is used in SIP to transfer ISUP messages. Regards, Christer Holmberg Ericsson Finland Mukesh R Shah wrote: > > hi , > > Can anyone tell me how MIME contents are handled in SIP ? > In case there is any RFC/draft on this topic, plz let me know. > > Thanks in advance > > Regards, > Mukesh > > ------------------------------------------------------------------------ > Name: InterScan_Disclaimer.txt > InterScan_Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 02:58:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17200 for ; Thu, 24 Jan 2002 02:58:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA16514 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 02:58:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15527; Thu, 24 Jan 2002 02:25:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15494 for ; Thu, 24 Jan 2002 02:25:49 -0500 (EST) Received: from pdc2proxy.wipro.com ([203.129.228.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16818 for ; Thu, 24 Jan 2002 02:25:43 -0500 (EST) Received: from pdc2vwall.wipro.com (pdc2vwall.wipro.com [10.111.14.18]) by pdc2proxy.wipro.com (8.11.3/8.11.3) with SMTP id g0O7NvA17306 for ; Thu, 24 Jan 2002 12:53:57 +0530 (IST) Received: from 10.111.12.18 by pdc2vwall.wipro.com (InterScan E-Mail VirusWall NT); Thu, 24 Jan 2002 12:54:39 +0530 Received: from HJNTNI108931 ([10.111.17.60]) by pdc2mail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GQFLX200.GU7 for ; Thu, 24 Jan 2002 12:54:38 +0530 Message-ID: <007201c1a4a9$108dc7c0$3c116f0a@HJNTNI108931> From: "Mukesh R Shah" To: Date: Thu, 24 Jan 2002 13:00:57 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-6f233573-0fd0-11d6-b423-00b0d0aa855a" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Sip] Regarding MIME content handling Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-6f233573-0fd0-11d6-b423-00b0d0aa855a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi , Can anyone tell me how MIME contents are handled in SIP ? In case there is any RFC/draft on this topic, plz let me know. Thanks in advance Regards, Mukesh ------=_NextPartTM-000-6f233573-0fd0-11d6-b423-00b0d0aa855a Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit ----------------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ----------------------------------------------------------------------------------------------------------------------------------- ------=_NextPartTM-000-6f233573-0fd0-11d6-b423-00b0d0aa855a-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 02:58:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17218 for ; Thu, 24 Jan 2002 02:58:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA16535 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 02:58:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15571; Thu, 24 Jan 2002 02:28:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA15544 for ; Thu, 24 Jan 2002 02:28:00 -0500 (EST) Received: from pdc2proxy.wipro.com ([203.129.228.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16824 for ; Thu, 24 Jan 2002 02:27:54 -0500 (EST) Received: from pdc2vwall.wipro.com (pdc2vwall.wipro.com [10.111.14.18]) by pdc2proxy.wipro.com (8.11.3/8.11.3) with SMTP id g0O7Q8A17315 for ; Thu, 24 Jan 2002 12:56:08 +0530 (IST) Received: from 10.111.12.18 by pdc2vwall.wipro.com (InterScan E-Mail VirusWall NT); Thu, 24 Jan 2002 12:56:50 +0530 Received: from HJNTNI108931 ([10.111.17.60]) by pdc2mail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GQFM0P00.LVW for ; Thu, 24 Jan 2002 12:56:49 +0530 Message-ID: <007801c1a4a9$5eb05fd0$3c116f0a@HJNTNI108931> From: "Mukesh R Shah" To: Date: Thu, 24 Jan 2002 13:03:08 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-6f233579-0fd0-11d6-b423-00b0d0aa855a" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Sip] Regarding Encrytion of SIP messages Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPartTM-000-6f233579-0fd0-11d6-b423-00b0d0aa855a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi , Is there any encryption technique used for SIP messages. plz let me know about it (RFC/drafts/links). Currently is there any who have implemented encryption on SIP messages ? Regards, Mukesh ------=_NextPartTM-000-6f233579-0fd0-11d6-b423-00b0d0aa855a Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit ----------------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ----------------------------------------------------------------------------------------------------------------------------------- ------=_NextPartTM-000-6f233579-0fd0-11d6-b423-00b0d0aa855a-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 03:01:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17271 for ; Thu, 24 Jan 2002 03:01:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA16862 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 03:01:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16111; Thu, 24 Jan 2002 02:35:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA16081 for ; Thu, 24 Jan 2002 02:34:59 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16959 for ; Thu, 24 Jan 2002 02:34:56 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0O7YuIB017605; Thu, 24 Jan 2002 08:34:56 +0100 (MET) Received: from lmf.ericsson.se (lmf04630pc.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0O7Yur6005352; Thu, 24 Jan 2002 09:34:56 +0200 (EET) Message-ID: <3C4FB91E.300D7D51@lmf.ericsson.se> Date: Thu, 24 Jan 2002 09:34:54 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mukesh R Shah , sip@ietf.org Subject: Re: [Sip] Regarding MIME content handling References: <007201c1a4a9$108dc7c0$3c116f0a@HJNTNI108931> <3C4FB818.3069EB9B@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Just a small correction: draft-ietf-sip-isup-mime-10.txt is now RFC 3204. Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > > Hi, > > MIME contents are "handled" in SIP like anywhere else. Please have a > look at the MIME RFCs. > > In draft-ietf-sip-isup-mime-10.txt you'll find an example how MIME is > used in SIP to transfer ISUP messages. > > Regards, > > Christer Holmberg > Ericsson Finland > > Mukesh R Shah wrote: > > > > hi , > > > > Can anyone tell me how MIME contents are handled in SIP ? > > In case there is any RFC/draft on this topic, plz let me know. > > > > Thanks in advance > > > > Regards, > > Mukesh > > > > ------------------------------------------------------------------------ > > Name: InterScan_Disclaimer.txt > > InterScan_Disclaimer.txt Type: Plain Text (text/plain) > > Encoding: 7bit > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 04:15:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18075 for ; Thu, 24 Jan 2002 04:15:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA19388 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 04:15:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18532; Thu, 24 Jan 2002 03:53:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18431 for ; Thu, 24 Jan 2002 03:53:30 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17751 for ; Thu, 24 Jan 2002 03:53:27 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0O8rQw08492; Thu, 24 Jan 2002 09:53:27 +0100 (MET) Received: from lmf.ericsson.se (lmf04630pc.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0O8rQr6012042; Thu, 24 Jan 2002 10:53:26 +0200 (EET) Message-ID: <3C4FCB84.CE78303@lmf.ericsson.se> Date: Thu, 24 Jan 2002 10:53:24 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Vijay Gurbani , sip@ietf.org Subject: Re: [Sip] Open Issue #144: Branch ID + isCancel() as transaction ID References: <3C210BE4.8090304@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have nothing against the proposal, but a couple of small issues we shouldn't forget. 1. Forking. The To-tag must still be used to separate responses from different servers. Nothing strange there, but one should be aware of it. 2. Message merging Until now, the branch id was used by an UAS to check if a received INVITE message was a re-transmit of a previous INVITE message, or the same INVITE but which has taken a DIFFERENT route, since the "old" transaction identifiers (To, From, Call-ID and CSeq) were the same in both cases. I guess the "old" identifiers, or at least parts (maybe the Call-ID and CSeq are enough?) of them, still have to be used for this purpose, don't they? Also, since different To tags will be used for the 482 messages(s) the receiver must check the To tag to be able to separate the responses, since they will all have the same branch id. Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > The rough consensus of IETF 52 was to accept this proposal, but a little > more detail is needed. > > Mike had pointed out some security vulnerabilities introduced by this; > namely, a malicious proxy could clobber other peoples transactions by > using their transaction keys in the via. Of course, it can always do > that today by inserting their to/from/call-id/via/r-uri, so its not much > different. However, there was agreement that the server would compute > the transaction key as a hash of the via branch ID, the source IP/port > and a private key. > > We also need to clarify that the proxy should construct the branch ID to > be unique, and document the specific cookie value. > > Any further comments? I feel strongly that we should do this, since it > will solve a LOT of interop problems that arise with looping and spirals > and the whole nine yards, which continue to plague us at bakeoffs. > > -Jonathan R. > > Vijay Gurbani wrote: > > > Jonathan Rosenberg wrote: > > > >>Issue: > >> > > [...] > > > >>Bis-05 has taken a big step forward with a rigorous definition of > >>transaction, which makes it clear that its a single "branch" in the tree > >>of requests formed when a UAC sends a request through a bunch of proxies. > >>That is, the To/From/CSeq/Call-ID identify the root of this tree, and the > >>Via branch + r-uri further identify each branch in the tree. Based on > >>this, it is natural to take the final step, and define the transaction ID > >>for a request/response MUCH more simply - it is the value of the branch ID > >>in the topmost via, with the small caveat that CANCEL has the same branch > >>ID, but its a different transaction. > >> > > > > Also that ACKs for non-2xx response must have the same branch ID as the > > INVITE did. > > > > [...] > > > > > >>Proposal: > >> > >>Allow for branch ID to be the transaction ID, by taking the steps > >>described above. > >> > > > > Fine. > > > > - vijay > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 07:10:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20104 for ; Thu, 24 Jan 2002 07:10:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA25140 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 07:10:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24381; Thu, 24 Jan 2002 06:44:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24348 for ; Thu, 24 Jan 2002 06:44:21 -0500 (EST) Received: from esuims01.esamsungumit.com ([203.122.29.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19839 for ; Thu, 24 Jan 2002 06:44:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 24 Jan 2002 17:19:06 +0530 Message-ID: <89CFEE6120A0224EA07781892EC0B48B589ABC@esuims01.esamsungumit.com> Thread-Topic: query Thread-Index: AcGkzSA9ARlftlFSSWK0EuXTwaDJ8A== From: "Sumit Kansal" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA24349 Subject: [Sip] query Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit i am working on SIP and i am reading draft-ietf-sip-rfc2543bis-05.ps with date october 26,2001 in section 8.1.3.1 on unrecognized responses it says that UAC treat unrecognized responses as x00 but if it receives code 211 say(i.e other than 200) then according to RFC it should be considered as 200 which is for OK . but it has received some errornous response so how this can be considered as OK please help me waiting for reply sumit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 10:11:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23045 for ; Thu, 24 Jan 2002 10:11:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02517 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 10:11:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01349; Thu, 24 Jan 2002 09:45:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01318 for ; Thu, 24 Jan 2002 09:45:45 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22615 for ; Thu, 24 Jan 2002 09:45:40 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0OEjDS01930 for ; Thu, 24 Jan 2002 08:45:13 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g0OEjDT27200 for ; Thu, 24 Jan 2002 08:45:13 -0600 (CST) Received: from lmf.ericsson.se (rmt160246.am.ericsson.se [138.85.160.246]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA14757; Thu, 24 Jan 2002 08:45:09 -0600 (CST) Message-ID: <3C5024F0.F17F309A@lmf.ericsson.se> Date: Thu, 24 Jan 2002 17:14:56 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] 1-of-N codecs + inband DTMF References: <3C4FAC2F.542DD7BB@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Christer, I believe that for complex scenarios you will be better off using FID. Simpler scenarios can be handled in the "unify" draff using vanilla SDP. Regards, Gonzalo Christer Holmberg wrote: > > Hi, > > This is not directly related to the unify draft, but to the "1-of-N > codecs" mechanism in general. > > Assume that we want to also use inband DTMF, according to RFC 2833. So, > since the DTMF from a SDP point of view now is a separate codec, in this > case the final codec selection would be 2-of-N codecs, because I don't > think anyone wants to send a re-INVITE everytime an inband DTMF is to be > sent... > > Do you think this special case should be mentioned somewhere in the > text? > > Regards, > > Christer Holmberg > Ericsson Finland > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 11:04:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25028 for ; Thu, 24 Jan 2002 11:04:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05072 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 11:04:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03573; Thu, 24 Jan 2002 10:38:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03540 for ; Thu, 24 Jan 2002 10:38:06 -0500 (EST) Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23896 for ; Thu, 24 Jan 2002 10:38:02 -0500 (EST) Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117]) by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id g0OFZ2P08314; Thu, 24 Jan 2002 10:35:02 -0500 Message-Id: <5.1.0.14.2.20020124101429.03142a60@mail.pingtel.com> X-Sender: jbatson@mail.pingtel.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 24 Jan 2002 10:34:30 -0500 To: "Henning G. Schulzrinne" , Juha Heinanen From: Jay Batson Subject: Re: [Sip] Open Issue #366: sip v. tel URL Cc: Dean Willis , Jonathan Rosenberg , sip@ietf.org In-Reply-To: <3C48383D.5B26A3C3@cs.columbia.edu> References: <3C34C2AD.3000301@dynamicsoft.com> <3C4751B1.8040208@dynamicsoft.com> <15431.48926.519889.351332@harjus.eng.song.fi> <00ca01c1a02a$0e3d1800$0a64a8c0@flak> <15432.11981.90292.43613@harjus.eng.song.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Though the moment is a bit past, I'd add my support to the suggestion Henning makes. One interesting parallel-behavior: I use Eudora for email, and can set up "personalities" -- a feature I use a lot. There's a root personality containing defaults, and other named personalities that permit me to set alternate values for various config parameters, e.g. what my reply-to address should be, etc. Oddly enough, one thing I *can't* set per-personality is my outbound SMTP server, and that drives me nuts! I'd like to associate my "home" personality with my broadband provider, since when I send email there I want it to go through their SMTP server. (As it is, I have to manually change the outbound SMTP server when I move around.) So I know that I really *want* the outbound (SMTP) server to be a configurable element of my mail user agent. In the same way, I like Henning's idea of a root/default for a user agent, and a provision for registrations/invites/... to be sent to a different server based on user agent capabilities & configurations. This sounds exactly like something I'd want from an end-user standpoint. -jb At 09:59 AM 1/18/02, Henning G. Schulzrinne wrote: >Juha Heinanen wrote: > > > > Dean Willis writes: > > > > > Why shouldn't the default domain to added by a SIP phone be a piece > of local > > > configuration information, just as it is for mail and DNS? > > > > because i can log in to a anybodies sip "phone" sitting in some ip > > subnet with whatever sip url i hapens to have. > > > >To make my proposal more concrete: If I log in as foo@example.com, my >home domain is example.com and this home domain will be used for >registrations and default domain for E.164 numbers (and maybe for >preloaded routes, if that matters). Does that work? > >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 11:10:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25280 for ; Thu, 24 Jan 2002 11:10:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05204 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 11:10:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04287; Thu, 24 Jan 2002 10:52:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04260 for ; Thu, 24 Jan 2002 10:52:21 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24376 for ; Thu, 24 Jan 2002 10:52:19 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0OFnxm2026575; Thu, 24 Jan 2002 10:49:59 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 10:51:50 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9CF@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Vijay Gurbani'" , Robert Sparks Cc: "'sip@ietf.org'" Subject: RE: [Sip] Open Issue #268 : port number and maddr Date: Thu, 24 Jan 2002 10:51:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > Proposed Resolution: > > > > If a port or transport parameter is specified in a URL > that contains > > an maddr parameter, the port and transport apply to the address > > indicated by the maddr parameter value. > > This is the existing behavior, if I am not mistaken. It is what we have agreed to on the list, but the spec has not been clear on this point. > > > So, the flow above would continue > > UAC 1.2.3.4 foo.com > > | INVITE sip:a@foo.com:6666;transport=tls;maddr=1.2.3.4 > > |-------------->| | > > | | INVITE sip:a@foo.com > > | |----------->| > > > > assuming 1.2.3.4 received the message over tls at port 6666. > > If 1.2.3.4 recieved the message on some other port or using > > some other transport, it would forward the message to port > > 6666 at 1.2.3.4 over tls. > > > > I am documenting this in bis now. Please comment quickly. > > I have no problems with the resolution. However, would something > like this be entertained: > > INVITE sip:a@foo.com:7777;maddr=1.2.3.4:9999:tls > > In other words, the maddr will have 2 optional values, > separated by :. > Here, port 7777 affects foo.com and port 9999 affects 1.2.3.4. > > While this has the nice property that all factors that affect > maddr are > in the maddr parameter, the biggest disadvantage is that it is NOT > backward compatible. In this case, that's a pretty big disadvantage - existing proxies would actually choke on that syntax. It looks like we can live with the limitations of the backwards compatible solution, so we should go it. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 12:01:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27388 for ; Thu, 24 Jan 2002 12:01:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09254 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 12:01:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06882; Thu, 24 Jan 2002 11:41:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06851 for ; Thu, 24 Jan 2002 11:41:08 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26436 for ; Thu, 24 Jan 2002 11:41:04 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0OGf0p21826; Thu, 24 Jan 2002 11:41:00 -0500 (EST) Received: from lucent.com (pctla2 [135.3.130.26]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id LAA21919; Thu, 24 Jan 2002 11:40:58 -0500 (EST) Message-ID: <3C503860.3ADAD396@lucent.com> Date: Thu, 24 Jan 2002 11:37:52 -0500 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP Mailing List , "Rosenberg, Jonathan" Content-Type: multipart/mixed; boundary="------------094845F68B5D1A01F57B2A6D" Subject: [Sip] Unify draft and 1-of-N Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------094845F68B5D1A01F57B2A6D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The method of section 5.1 nicely solves the 1-of-N problem, but I assume we still want to support the N-of-N or M-of-N approach as well for devices that do NOT have the limitiation. How do caller and callee indicate the new interpretation of the m line in the initial INVITE? Caller controls the option to send a new INVITE, but unless the second INVITE (or a COMET) is REQUIRED, caller may try to use all M codecs returned by callee. If the 2nd INVITE (or COMET) is required, I think M-of-N can be supported. Caller returns all M in 2nd INVITE if it can support them simultaneously and Callee can return M or 1 in 2nd 200 OK depending on its capability. The problem is if Caller has no restriction and decides not to send 2nd INVITE - Callee has no way to indicate its limitation. Was it intended for bis to require the second INVITE? Of course if neither had the restriction, the second message exchange was not needed, but that is they way they find out. If the restriction or not was indicated in the first INVITE and 200 OK, the 2nd could be saved when it was found neither had the restriction. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------094845F68B5D1A01F57B2A6D Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard --------------094845F68B5D1A01F57B2A6D-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 14:21:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02888 for ; Thu, 24 Jan 2002 14:20:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16770 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 14:20:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14774; Thu, 24 Jan 2002 13:54:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14707 for ; Thu, 24 Jan 2002 13:54:01 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02126; Thu, 24 Jan 2002 13:53:56 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA25967; Thu, 24 Jan 2002 10:53:03 -0800 (PST) Message-ID: <3C50582C.E67C00C2@cisco.com> Date: Thu, 24 Jan 2002 13:53:32 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: Juha Heinanen , Dean Willis , sipping@ietf.org, sip@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] calling number blocking at sip/isup gateway Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > ok, i tried again and still can't figure out how my proxy can tell to > a > > trusted sip/isup gw that the calling user doesn't want his/her phone > > number to be shown to the called pstn user. i would like to be able > to > > do something simple in the proxy, like adding a header > > > > Anonymity: from > > > > to the invite, but that kind of thing is not available. my suggestion > > is that the authors of the privacy i-d and the sip-isup i-d figure it > > out how to map isup Calling party indicator "Address presentation > > restricted" to/from sip. before that is done, i would not vote going > > forward with either i-d. > > There is an obvious tension between four issues: > > - The fact that when an UA is under the user's control, the content of > the header fields can be set to arbitrary values, and that any header > field can be expected to be read by the final user; > - The legal requirement in many countries for "traceability", i.e. the > possibility for law enforcement to find the source of any phone call; > - The desire in many cases to place anonymous calls, i.e. without > disclosing the identity and/or the location of the caller (Think > "whistle blower"); > - The desire in even more cases to block anonymous calls (Think spam). > > The mix of the four makes for an unsavory soup. In the privacy draft, > the law enforcement requirement can only be met by letting a proxy > insert a "Remote-Party-ID" header; but the moment you do that, you > enable every party down the chain to see and display that header. To > prevent abuse, the draft creates a "RPID-Privacy" header that the caller > should set to the appropriate value if it does not want the information > casually displayed. > > Frankly, I am amazed by the naivety of the proposal. To make this work, > you then need a "chain of trust" between all the proxies; Not all the proxies - only the proxies within your trust boundary. As a special case of this, a proxy may not trust any other proxies and hence always encrypt the Remote-Party-Id with privacy indication before forwarding the message. > yet, we have > no mechanism to determine this level of trust. We also need to assume > that the information will not be displayed by the called UA regardless > of the value in the privacy field, No. There is an explicit distinction between forwarding messages to trusted and non-trusted entities. Whenever you forward a message to an untrusted entity, and privacy has been requested, you will encrypt the Remote-Party-ID information. It's never passed in clear to an untrusted entity. > which goes contrary to what we see > with e-mail, and also goes contrary to the obvious desire to fight spam. > > Frankly, I don't find this privacy draft useful or adequate. It attempts > to comply with telephony-era regulations that have basically no meaning > in the Internet. In fact, we could probably meet these regulations by > having a much simpler solution that directly target ISUP compatibility: > a calling telephone number header, with a privacy tag, that gateways to > the telephone network could directly translate. > This doesn't change any of the fundamental problems and solutions in the draft. All you are saying, is that the only identity information that can be provided and protected are telephone-numbers. The more general SIP-URLs will not have this ability and hence cannot be used if we wanted to provide a similar service. I don't think that's very compelling. -- Flemming PS: This discussion should probably be moved to the SIP list. > > -- Christian Huitema > > _______________________________________________ > 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 -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 15:03:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04088 for ; Thu, 24 Jan 2002 15:03:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19125 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 15:03:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17809; Thu, 24 Jan 2002 14:40:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17780 for ; Thu, 24 Jan 2002 14:40:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03359 for ; Thu, 24 Jan 2002 14:40:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OJeKGe029711 for ; Thu, 24 Jan 2002 14:40:20 -0500 (EST) Message-ID: <3C5062FE.84AA4C91@dynamicsoft.com> Date: Thu, 24 Jan 2002 14:39:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] update to draft-ietf-sip-srv Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I've just submitted an update to draft-ietf-sip-srv. This is based primarily on feedback from IESG folks on the proper way to do NAPTR handling, as it was wrong in -03. Until it appears, you can fetch it from: http://www.jdrosen.net/papers/draft-ietf-sip-srv-04.txt Changes are noted in a changes section. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 15:20:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04523 for ; Thu, 24 Jan 2002 15:20:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19960 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 15:20:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18547; Thu, 24 Jan 2002 15:00:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18500 for ; Thu, 24 Jan 2002 15:00:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03966 for ; Thu, 24 Jan 2002 15:00:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OK0FGe029760; Thu, 24 Jan 2002 15:00:15 -0500 (EST) Message-ID: <3C5067A8.679DEBC7@dynamicsoft.com> Date: Thu, 24 Jan 2002 14:59:36 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Vijay Gurbani , sip@ietf.org Subject: Re: [Sip] Open Issue #144: Branch ID + isCancel() as transactionID References: <3C4FCB84.CE78303@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > I have nothing against the proposal, but a couple of small issues we > shouldn't forget. > > 1. Forking. > > The To-tag must still be used to separate responses from different > servers. Nothing strange there, but one should be aware of it. This is orthogonal and unrelated. Usage of tags is for dialog matching and I believe is well documented in bis-05. > > 2. Message merging > > Until now, the branch id was used by an UAS to check if a received > INVITE message was a re-transmit of a previous INVITE message, or the > same INVITE but which has taken a DIFFERENT route, since the "old" > transaction identifiers (To, From, Call-ID and CSeq) were the same in > both cases. I guess the "old" identifiers, or at least parts (maybe the > Call-ID and CSeq are enough?) of them, still have to be used for this > purpose, don't they? A merged request would appear as a different transaction, with a different branch ID. If the proxy cares to determine that this is a merge (generally not necessary), it could look at to/from/call-id/cseq if it wants, but there is no reason as far as I can tell. Proxies do not handle merging, only UAs. > > Also, since different To tags will be used for the 482 messages(s) the > receiver must check the To tag to be able to separate the responses, > since they will all have the same branch id. Huh?? They will most certainly NOT have the same branch ID. When a proxy forks, each branch has a separate branch ID. For each transaction, there is a unique transaction ID, and that is the value of the branch ID, period. It is very simple now. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 15:25:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04613 for ; Thu, 24 Jan 2002 15:25:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20164 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 15:25:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18877; Thu, 24 Jan 2002 15:01:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18849 for ; Thu, 24 Jan 2002 15:01:05 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04013 for ; Thu, 24 Jan 2002 15:01:01 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OK1AGe029763; Thu, 24 Jan 2002 15:01:10 -0500 (EST) Message-ID: <3C5067E0.746DF3D0@dynamicsoft.com> Date: Thu, 24 Jan 2002 15:00:32 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mukesh R Shah CC: sip@ietf.org Subject: Re: [Sip] Regarding Encrytion of SIP messages References: <007801c1a4a9$5eb05fd0$3c116f0a@HJNTNI108931> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Mukesh R Shah wrote: > > hi , > > Is there any encryption technique used for SIP messages. > plz let me know about it (RFC/drafts/links). > > Currently is there any who have implemented encryption on SIP messages ? RFC2543 supported PGP, but this has been deprecated in bis. Instead S/MIME will exist for the purposes of encryption. There will be a good amount of detail on S/MIME in the forthcoming bis-06. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 15:25:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04632 for ; Thu, 24 Jan 2002 15:25:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20182 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 15:25:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18270; Thu, 24 Jan 2002 14:54:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18242 for ; Thu, 24 Jan 2002 14:54:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03832 for ; Thu, 24 Jan 2002 14:54:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OJslGe029754; Thu, 24 Jan 2002 14:54:48 -0500 (EST) Message-ID: <3C506661.D2C02DCF@dynamicsoft.com> Date: Thu, 24 Jan 2002 14:54:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: SIP Mailing List References: <3C503860.3ADAD396@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Unify draft and 1-of-N Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Terry L Anderson wrote: > > The method of section 5.1 nicely solves the 1-of-N problem, but I assume > we still want to support the N-of-N or M-of-N approach as well for > devices that do NOT have the limitiation. That works as well with the mechanism. > > How do caller and callee indicate the new interpretation of the m line > in the initial INVITE? Caller controls the option to send a new INVITE, > but unless the second INVITE (or a COMET) is REQUIRED, caller may try to > use all M codecs returned by callee. I don't follow the problem. The callee knows the full set of codecs from the initial INVITE, so it places in the response whichever ones it is capable of simultaneously receiving. For example, lets say A calls B. A supports codecs X,Y,Z, and B supports Y and Z. A can only do one codec at a time, B can do either Y or Z simultaneously. AN initial INVITE would look like: INVITE: m=audio 2024 RTP/AVP X Y Z a=inactive 200 OK: m=audio 2024 RTP/ACP Y Z a=inactive ACK: re-INVITE: m=audio 2024 RTP/AVP Y a=sendrecv 200 OK: m=audio 2024 RTP/AVP Y a=sendrecv Seems to work fine. In the event where A has no restrictions, but B can only do two of X,Y,Z, the initial INVITE would list X,Y,Z, and the 200 OK would allow B two pick any two, and return that. There would not be a second exchange. > > If the 2nd INVITE (or COMET) is required, I think M-of-N can be > supported. Caller returns all M in 2nd INVITE if it can support them > simultaneously and Callee can return M or 1 in 2nd 200 OK depending on > its capability. The problem is if Caller has no restriction and decides > not to send 2nd INVITE - Callee has no way to indicate its limitation. It would indicate its limitations in the 200 OK to the initial INVITE. If you believe there is still a problem, please send a specific flow that doesn't work. > > Was it intended for bis to require the second INVITE? No. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 15:34:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04916 for ; Thu, 24 Jan 2002 15:34:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21015 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 15:34:33 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19700; Thu, 24 Jan 2002 15:15:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19635 for ; Thu, 24 Jan 2002 15:15:40 -0500 (EST) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04375; Thu, 24 Jan 2002 15:15:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Re: [Sipping] calling number blocking at sip/isup gateway Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 24 Jan 2002 14:15:05 -0600 Message-ID: Thread-Topic: [Sip] Re: [Sipping] calling number blocking at sip/isup gateway Thread-Index: AcGlC3BnWGL065GFQwSJAIWJ/mb7IgABJpbA From: "Chiou, Mark" To: "Flemming Andreasen" , "Christian Huitema" Cc: "Juha Heinanen" , "Dean Willis" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA19636 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi All, For Address presentation information, can we use the DISPLAY-name field in the name-addr header to store calling name and number? For example, From : Anonymity, 1234567;tag=3pcc --- to indicate restriction on calling number Then SIP-to-ISUP gateway can build "Address presentation information" from extracting calling number from From's DISPLAY name field if the number is missing from userinfo and set the Address presentation to restricted. My 2 cents thought, Mark Chiou -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: Thursday, January 24, 2002 12:54 PM To: Christian Huitema Cc: Juha Heinanen; Dean Willis; sipping@ietf.org; sip@ietf.org Subject: [Sip] Re: [Sipping] calling number blocking at sip/isup gateway Christian Huitema wrote: > > ok, i tried again and still can't figure out how my proxy can tell to > a > > trusted sip/isup gw that the calling user doesn't want his/her phone > > number to be shown to the called pstn user. i would like to be able > to > > do something simple in the proxy, like adding a header > > > > Anonymity: from > > > > to the invite, but that kind of thing is not available. my suggestion > > is that the authors of the privacy i-d and the sip-isup i-d figure it > > out how to map isup Calling party indicator "Address presentation > > restricted" to/from sip. before that is done, i would not vote going > > forward with either i-d. > > There is an obvious tension between four issues: > > - The fact that when an UA is under the user's control, the content of > the header fields can be set to arbitrary values, and that any header > field can be expected to be read by the final user; > - The legal requirement in many countries for "traceability", i.e. the > possibility for law enforcement to find the source of any phone call; > - The desire in many cases to place anonymous calls, i.e. without > disclosing the identity and/or the location of the caller (Think > "whistle blower"); > - The desire in even more cases to block anonymous calls (Think spam). > > The mix of the four makes for an unsavory soup. In the privacy draft, > the law enforcement requirement can only be met by letting a proxy > insert a "Remote-Party-ID" header; but the moment you do that, you > enable every party down the chain to see and display that header. To > prevent abuse, the draft creates a "RPID-Privacy" header that the caller > should set to the appropriate value if it does not want the information > casually displayed. > > Frankly, I am amazed by the naivety of the proposal. To make this work, > you then need a "chain of trust" between all the proxies; Not all the proxies - only the proxies within your trust boundary. As a special case of this, a proxy may not trust any other proxies and hence always encrypt the Remote-Party-Id with privacy indication before forwarding the message. > yet, we have > no mechanism to determine this level of trust. We also need to assume > that the information will not be displayed by the called UA regardless > of the value in the privacy field, No. There is an explicit distinction between forwarding messages to trusted and non-trusted entities. Whenever you forward a message to an untrusted entity, and privacy has been requested, you will encrypt the Remote-Party-ID information. It's never passed in clear to an untrusted entity. > which goes contrary to what we see > with e-mail, and also goes contrary to the obvious desire to fight spam. > > Frankly, I don't find this privacy draft useful or adequate. It attempts > to comply with telephony-era regulations that have basically no meaning > in the Internet. In fact, we could probably meet these regulations by > having a much simpler solution that directly target ISUP compatibility: > a calling telephone number header, with a privacy tag, that gateways to > the telephone network could directly translate. > This doesn't change any of the fundamental problems and solutions in the draft. All you are saying, is that the only identity information that can be provided and protected are telephone-numbers. The more general SIP-URLs will not have this ability and hence cannot be used if we wanted to provide a similar service. I don't think that's very compelling. -- Flemming PS: This discussion should probably be moved to the SIP list. > > -- Christian Huitema > > _______________________________________________ > 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 -- Flemming Andreasen Cisco Systems _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 15:40:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05074 for ; Thu, 24 Jan 2002 15:40:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21241 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 15:40:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19938; Thu, 24 Jan 2002 15:19:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19908 for ; Thu, 24 Jan 2002 15:18:58 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04479 for ; Thu, 24 Jan 2002 15:18:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OKJ0Ge029788; Thu, 24 Jan 2002 15:19:00 -0500 (EST) Message-ID: <3C506C0D.1EB8AC5@dynamicsoft.com> Date: Thu, 24 Jan 2002 15:18:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Gurbani CC: Robert Sparks , "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #268 : port number and maddr References: <3C4F21F1.3CDB8099@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Vijay Gurbani wrote: > > > assuming 1.2.3.4 received the message over tls at port 6666. > > If 1.2.3.4 recieved the message on some other port or using > > some other transport, it would forward the message to port > > 6666 at 1.2.3.4 over tls. > > > > I am documenting this in bis now. Please comment quickly. > > I have no problems with the resolution. However, would something > like this be entertained: > > INVITE sip:a@foo.com:7777;maddr=1.2.3.4:9999:tls > > In other words, the maddr will have 2 optional values, separated by :. > Here, port 7777 affects foo.com and port 9999 affects 1.2.3.4. > > While this has the nice property that all factors that affect maddr are > in the maddr parameter, the biggest disadvantage is that it is NOT > backward compatible. I'm going to take this moment to describe our basic aim with "backwards compatibility" for SIP. First off, the primary aim is NOT backwards compatibility with 2543, but backwards compatibility with existing implementations, with greater concern for things that are deployed or cannot be easily changed with any speed. Second, there are definitely cases where we have lost interop - generally, under specific conditions and scenarios, something stops working. I think it is acceptable to lose such interop when the conditions or scenarios are deemed sufficiently unlikely. However, a change which means that failure will occur in all scenarios, that is not acceptable. Unfortunately, that is the case with Vijay's proposal above. It has been proposed before at least a few times before, and still has the same problem now it had then. It breaks in all cases. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 15:45:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05138 for ; Thu, 24 Jan 2002 15:45:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21443 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 15:45:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20020; Thu, 24 Jan 2002 15:21:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19995 for ; Thu, 24 Jan 2002 15:21:51 -0500 (EST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04555 for ; Thu, 24 Jan 2002 15:21:47 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Thu, 24 Jan 2002 12:21:18 -0800 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 24 Jan 2002 12:21:18 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 24 Jan 2002 12:21:18 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 24 Jan 2002 12:21:18 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 24 Jan 2002 12:19:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] solving early media, HERFP, and unifying manyfolks Date: Thu, 24 Jan 2002 12:19:04 -0800 Message-ID: Thread-Topic: [Sip] solving early media, HERFP, and unifying manyfolks thread-index: AcGfjpv5gTsvY42/SSaUXoGwjQ40owFhIeDA From: "Christian Huitema" To: "Jonathan Rosenberg" , X-OriginalArrivalTime: 24 Jan 2002 20:19:04.0519 (UTC) FILETIME=[5E6C9D70:01C1A514] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA19996 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Jonathan, I had a look at the licensing term that you are proposing to use, and the advice I got was the language is overly broad and cumbersome, and implicates more than just what is in this spec. The problem is that the phrase "any patent or other intellectual property right" is not qualified by a scope, such as "for the implementation of this standard." What about patents or other IPR that is not necessary for implementing SIP, e.g. patents on graphical displays, speech recognition algorithms, even speech compression algorithms? -- Christian Huitema > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, January 17, 2002 11:39 AM > To: sip@ietf.org; Jonathan Rosenberg > Subject: [Sip] solving early media, HERFP, and unifying manyfolks > > Folks, > > I've been working on some of the open issues in bis, mainly HERFP, the > usage of a three-way SDP exchange, overlapping INVITE, and unification > of O/A with manyfolks. In the process, I came up with a joint solution > to all of these problems. I have written it up, along with call flows > showing how it is used in all cases, in an I-D that I have just > submitted. Until that I-D appears, you may pick it up at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt > > In summary, the draft proposes that COMET take on a new, much broader > definition, encompassing the semantics of UPDATE, and then some, as has > been discussed on the list. The draft postulates how manyfolks can be > recast to fit within the offer/answer model, and then shows how COMET > can also be used to update not just session parameters, but other state, > in an effort to resolve HERFP. For those confused about what HERFP is, > it is a rather nasty forking problem that interferes with services, it > is discussed in detail in the above draft. > > The proposal would change bis in a simple way, which is to generalize > the conditions under which SDP could appear in SIP. THis generalization > would imply the current behavior (INV/200 or 200/ACK) for baseline > implementations, but would support richer exchanges for those supporting > the new COMET. Furthermore, the draft proposes that manyfolks be > sufficiently generalized to provide this new form of COMET. > > I would also like to point out that dynamicsoft may have IPR against > this draft. I will say, honestly, that we have been forced into the > corner of making IPR claims against IETF documents due to the existence > of claims against IETF documents that have been made by others. However, > our aim is ONLY defensive. As such, I have worked with our attorneys to > work out licensing terms which I think everyone will find most > agreeable, and indeed, laudable. They are: > > > > > dynamicsoft may seek patent protection on technology described in > documents which dynamicsoft submits for use in IETF standards > discussions. In relation to any IETF standard incorporating any such > technology, dynamicsoft will grant a royalty free non-exclusive license > to Qualified Parties to utilize such technology if necessary for > practice of IETF standards implemented as a result of dynamicsoft's > submission. As used herein, Qualified Parties means a party who has > not, does not and will not assert, in litigation or otherwise, including > in licensing discussions, any patent or other intellectual property > right against dynamicsoft. Any such license to a Qualified Party shall > terminate at once if such party asserts a patent or other intellectual > property right against dynamicsoft. dynamicsoft will grant > non-exclusive licenses to Non-Qualified Parties on reasonable, > reciprocal non-discriminatory terms and conditions. > > > These terms will also appear shortly on the IPR claims page at the IETF > site. A summary of these terms is basically "leave us alone, and this is > free". We feel that this is very much in the spirit of the IETF > practices and attitudes towards IPR, but recognizes that companies have > a need to protect themselves. I would encourage others who have IPR to > make their IPR available under similar terms, so we can focus on > technology work rather than acting as amateur lawyers. > > Comments and questions welcome, as always. > > -Jonathan R. > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 15:47:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05223 for ; Thu, 24 Jan 2002 15:47:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21590 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 15:47:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20393; Thu, 24 Jan 2002 15:28:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20292 for ; Thu, 24 Jan 2002 15:28:20 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04699 for ; Thu, 24 Jan 2002 15:28:17 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0OKRm224323; Thu, 24 Jan 2002 15:27:48 -0500 (EST) Received: from lucent.com (pctla2 [135.3.130.26]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id PAA03059; Thu, 24 Jan 2002 15:27:46 -0500 (EST) Message-ID: <3C506D88.35D936A2@lucent.com> Date: Thu, 24 Jan 2002 15:24:40 -0500 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: SIP Mailing List Subject: Re: [Sip] Re: Unify draft and 1-of-N References: <3C503860.3ADAD396@lucent.com> <3C506661.D2C02DCF@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------94CB1CB77D4FEB7E9F0EEF20" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------94CB1CB77D4FEB7E9F0EEF20 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Perhaps my confusion is simply that the behavior of each party in 5.1 is not carefully specified. I read it as BOTH caller and callee send ALL codecs supported (even if restricted to 1 of N) in first exchange. If so and the 2nd INVITE is optional at the choice of caller then here's the problem: caller supports M of N simultaneously, callee is restricted to 1 of N caller sends: 0 4 8 15 97 on m line (all it can support but can only support 2 simultaneously) callee can support 0 and 15 but only 1 simultaneously, thinking that the new mechanism is in use (that caller MAY support only 1 of N) callee returns 0 15 on m line of 200 OK (or was callee supposed to choose only one and indicate the rest using simcap if callee can support only 1 of N, rather than "ALL of the codecs supported by the UA, even if they cannot be supported simultaneously" as caller did?) caller now decides that 0 and 8 are in common and can support 2 simultaneously so there is no need for 2nd INVITE and so just begins using 0 and 15 interchangably. Callee cannot handle this. Or possibly what I am missing is that Caller indicates use of "new mechanism" by sending inactive in the initial INVITE. I guess if caller does this he is obligated to send another INVITE (or COMET) to change to sendrecv and so callee will have a later 200 OK that can be used to reduce list to one codec. Jonathan Rosenberg wrote: > Terry L Anderson wrote: > > > > The method of section 5.1 nicely solves the 1-of-N problem, but I assume > > we still want to support the N-of-N or M-of-N approach as well for > > devices that do NOT have the limitiation. > > That works as well with the mechanism. > > > > > How do caller and callee indicate the new interpretation of the m line > > in the initial INVITE? Caller controls the option to send a new INVITE, > > but unless the second INVITE (or a COMET) is REQUIRED, caller may try to > > use all M codecs returned by callee. > > I don't follow the problem. The callee knows the full set of codecs from > the initial INVITE, so it places in the response whichever ones it is > capable of simultaneously receiving. > > For example, lets say A calls B. A supports codecs X,Y,Z, and B supports > Y and Z. A can only do one codec at a time, B can do either Y or Z > simultaneously. AN initial INVITE would look like: > > INVITE: > > m=audio 2024 RTP/AVP X Y Z > a=inactive > > 200 OK: > m=audio 2024 RTP/ACP Y Z > a=inactive > > ACK: > > re-INVITE: > > m=audio 2024 RTP/AVP Y > a=sendrecv > > 200 OK: > m=audio 2024 RTP/AVP Y > a=sendrecv > > Seems to work fine. In the event where A has no restrictions, but B can > only do two of X,Y,Z, the initial INVITE would list X,Y,Z, and the 200 > OK would allow B two pick any two, and return that. There would not be a > second exchange. > > > > > If the 2nd INVITE (or COMET) is required, I think M-of-N can be > > supported. Caller returns all M in 2nd INVITE if it can support them > > simultaneously and Callee can return M or 1 in 2nd 200 OK depending on > > its capability. The problem is if Caller has no restriction and decides > > not to send 2nd INVITE - Callee has no way to indicate its limitation. > > It would indicate its limitations in the 200 OK to the initial INVITE. > If you believe there is still a problem, please send a specific flow > that doesn't work. > > > > > Was it intended for bis to require the second INVITE? > > No. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------94CB1CB77D4FEB7E9F0EEF20 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard --------------94CB1CB77D4FEB7E9F0EEF20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 15:53:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05386 for ; Thu, 24 Jan 2002 15:53:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21908 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 15:53:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21058; Thu, 24 Jan 2002 15:35:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21030 for ; Thu, 24 Jan 2002 15:35:20 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04977 for ; Thu, 24 Jan 2002 15:35:16 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OKZQGe029795; Thu, 24 Jan 2002 15:35:26 -0500 (EST) Message-ID: <3C506FE4.38145FAF@dynamicsoft.com> Date: Thu, 24 Jan 2002 15:34:44 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] Comments on "unify" draft References: <200201222059.PAA44216@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > Jonathan wrote: > > > > In general, it would be helpful to get general feedback of the form > > "seems like the right direction". Particularly, the main thing I need > > feedback on ASAP is the proposal to pretty much keep this all out of > > bis. The only thing in bis would be some generalized statement of when > > > you can see offers and answers, so that we can separate the > > EM/manyfolks/herfp solutions from bis. Granted, this stuff still needs > > > to be on the fast track for 3g, but I want to get it separated from > bis. > > > > First, I definitely agree this aspect should be decided quickly. > > I may be in the minority, but I think that a problem in 2543 should > be fixed in the next version of the RFC, and that HERFP qualifies > as a bug in 2543. It seems wrong to have a "supported:" tag defined > for a fix for a bug. This tag will be present irregardless of where this text lives. This is needed to enable compatibility with existing sip implementations, most of which follow one of the earlier bis drafts. Note that even though 100rel is folded into bis, it still requires usage of the Supported header. > > The main argument against this that I see is one of backwards > compatability. But everyone seems to agree that a UA or proxy > written to conform to 2543 is nearly useless - so the question > seems to be one of backwards compatability to what? To existing implementations that are deployed, or are about to be deployed and cannot be quickly changed. That is all that matters. According to formal IETF process, we have no requirement at all for backwards compatibility as far as I know; we are trying to maintain as much as possible to preserve continued operation of the protocol. > Do we really > need to maintain backwards comatability to a I-D, defined as only > a "Work in Progress"? With the definition of Route and Record-Route > in bis, we've already given up backwards compatability with a > pure-2543 proxy, and a fix for HERFP does not make the situation > any worse. See above, Bill. There is no UA I know of in any deployed situation that is purely 2543 compliant, since the RR processing there was simply underspecified. Most are following one of the earlier bis drafts. > > Second point is that 2543 already allows 1-of-N codec negotiation > through the use of a 3-way handshake (SDP in INVITE, subset in 200, > new SDP in ACK). So the statement that the 3-way handshake is not > backwards compatible is only with bis, not 2543, since the restriction > to offer/answer appears only in bis. I would argue that 2543 was simply unclear on this point entirely. It was never my impression that it allowed it, however, I can see how one my come to that conclusion (there is a sentence somewhere on updating the SDP in the ACK). SDP usage in rfc2543 was vastly underpsecified, overall. I would argue that most implementations today still only support SDP in INVITE/200, with nothing in the ACK. A few are beginning to support 200/ACK offer/answers. > Again this seems to be a > problem in bis, and should be fixed in bis. Offer/Counter-Offer/Answer > is a much cleaner solution than a two-stage invite (although as an > author > of the original two-stage invite proposal, > draft-dcsgroup-mmusic-resource-00, > June 1999, it is interesting that it has returned; all that is missing > is the No-Ring header in the first invite!). Bill, these snide remarks get us nowhere. As you are well aware, the issues with the two-stage invite in the original DCS had everything to do with the fact that the original INVITE was answered. Furthermore, even without answering the initial one, a two-stage INVITE is sufficiently complex, from a dialog-maintenance point of view, that we are not going to allow it. That is why it is INVITE followed by COMET instead. I would still like to know in what ways an three-way exchange is cleaner? It is a few messages shorter, for sure. However, it cannot do anything the two two-pass cannot do, either functionally, or in terms of latency. However, it adds complexity, since now we have two exchange mechanisms, and we will need to worry about how this interacts with 3pcc, how to signal which one is being used in which cases, and so on. The proposal eliminates all of that. As an example, with a three-pass exchange, the initial INVITE would need to indicate whether a counter-offer was expected, or just an answer. That requires a REquire header. Then, the UA will need to fall back to a regular offer/answer in the case it fails. The 200 OK, of course, would need an indicator somewhere about whether its an answer or counter-offer. If itsa counter-offer, we need to now specify procedures for error handling if the answer doesn't come in ACK, and so on. > > The early media, and handling of multiple early media streams, and > resource reservation before alerting, all seem to be more "extensions" > than "bugs", so I'd agree with them being in separate drafts. The line is fine indeed. I think a convincing argument could be made for it on either side. However, the argument is really philosophical in nature, and I am more concerned with practical issues right now. > But if > COMET (or UPDATE) is defined in bis, these drafts would be short. My main concern, and I am surprised its not yours as well, is timely completion of bis for 3gpp. To do that, we require parallelism. I would very much like to last call bis-06 as issued, and we could do that shortly if this stuff stays out. In parallel with the last call period, and iesg review, we can refine UPDATE/COMET, as this will take some time. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 15:59:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05652 for ; Thu, 24 Jan 2002 15:59:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22197 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 15:59:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21348; Thu, 24 Jan 2002 15:41:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21281 for ; Thu, 24 Jan 2002 15:41:10 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05095; Thu, 24 Jan 2002 15:41:05 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0OKewio000708; Thu, 24 Jan 2002 22:40:58 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15440.29018.371343.669653@harjus.eng.song.fi> Date: Thu, 24 Jan 2002 22:40:58 +0200 To: "Chiou, Mark" Cc: "Flemming Andreasen" , "Christian Huitema" , "Dean Willis" , , Subject: RE: [Sip] Re: [Sipping] calling number blocking at sip/isup gateway In-Reply-To: References: X-Mailer: VM 6.99 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Chiou, Mark writes: > For Address presentation information, can we use the DISPLAY-name field > in the name-addr header to store calling name and number? > For example, > From : Anonymity, 1234567;tag=3pcc > --- to indicate restriction on calling number > Then SIP-to-ISUP gateway can build "Address presentation information" > from extracting calling number from From's DISPLAY name field if the > number is missing from userinfo and set the Address presentation to > restricted. if this is how people want to do it, then it should be clearly documented in the sip-isup i-d. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 16:01:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05771 for ; Thu, 24 Jan 2002 16:01:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA22712 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 16:01:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21572; Thu, 24 Jan 2002 15:46:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21539 for ; Thu, 24 Jan 2002 15:46:40 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05199 for ; Thu, 24 Jan 2002 15:46:36 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OKkiGe029805; Thu, 24 Jan 2002 15:46:44 -0500 (EST) Message-ID: <3C50728A.8166458@dynamicsoft.com> Date: Thu, 24 Jan 2002 15:46:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Gurbani CC: sip@ietf.org, wtm@research.att.com Subject: Re: [Sip] Comments on "unify" draft References: <3C4ED2D0.2F9952B6@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Vijay Gurbani wrote: > > Jonathan Rosenberg wrote: > > In general, it would be helpful to get general feedback of the form > > "seems like the right direction". > [...] > > William Marshall wrote: > > I may be in the minority, but I think that a problem in 2543 should > > be fixed in the next version of the RFC, and that HERFP qualifies > > as a bug in 2543. It seems wrong to have a "supported:" tag defined > > for a fix for a bug. > > For whatever it is worth, I agree with Bill here. We should fix the > HERFP > problem in the bis. Solving HERFP through an extension (which almost > everyone will need to implement for a production grade system) is > probably > taking the easy way out. No, I don't think so. I do not think its needed for a production grade system yet. It happens under select conditions, namely, when forking occurs AND the UAS are going to reject the request because some aspect of it is not acceptable. That includes 401 and 415 mainly, and since few are doing e2e authentication, and even fewer sending non-SDP content in requests that will fork, well, its not an urgent problem. It will be an urgent problem when we begin to roll out SDPng, and when we begin to see more e2e security. As I argued in my response to Bill, there is a pure practical issue here, timely completion of bis. I consider the mechanisms needed to solve this problem sufficiently standalone, and sufficiently different from general sip operation, and sufficiently new (in terms of requring supported/require), that an extension makes sense in any case. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 16:16:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06168 for ; Thu, 24 Jan 2002 16:16:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA23854 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 16:16:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21802; Thu, 24 Jan 2002 15:52:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21751 for ; Thu, 24 Jan 2002 15:52:05 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05349 for ; Thu, 24 Jan 2002 15:52:01 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0OKnbm2029627; Thu, 24 Jan 2002 15:49:37 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 15:51:28 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9D7@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Sean Olson'" , "Vijay K. Gurbani" , Jonathan Rosenberg Cc: Christer Holmberg , Robert Sparks , james.yu@neustar.com, SIP WG List Subject: RE: [Sip] Issues with telephone-subscriber appearing in a SIP Date: Thu, 24 Jan 2002 15:51:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Nobody has argued with this in a couple of days. Based on these discussions, I'm planning to proceed with option 3 (documenting the limitations and suggesting a way of creating sip URIs from tel URIs that improves the chances of a case-sensitive blob comparison of the userpart of a SIP URI producing the same results as tel URL comparison. RjS > -----Original Message----- > From: Sean Olson [mailto:seancolson@yahoo.com] > Sent: Tuesday, January 22, 2002 9:41 AM > To: Vijay K. Gurbani; Jonathan Rosenberg > Cc: Christer Holmberg; rsparks@dynamicsoft.com; james.yu@neustar.com; > SIP WG List > Subject: Re: [Sip] Issues with telephone-subscriber appearing in a SIP > > > > > > I think we need to consider the pros/cons of that. > > I only vaguely > > > remember the email discussion that led to the > > conclusion to put them in > > > the user part. Certainly, collision of params is > > one part. Another part > > > is URI comparison; it becomes harder with them as > > params, since one > > > element that doesn't understand tel would ignore > > the params, whereas > > > they would be needed for comparison of the tel URL > > itself. Thus, > > > equivalency would be different as a sip URL v. a > > tel URL, which seems wrong. > > > > Namespace collision could be mitigated by the LNP > > I-D (when it becomes a RFC) > > defining a protected namespace for these parameters. > > This doesn't help. The potential collision stems > from using the same parameter name in both > the SIP URL and the "tel" portion of the user part. > > > > > Regarding equivalency being different on a SIP URL > > vs. a tel URL, isn't that > > what we want? In other words, > > > sip:+1-202-533-1234;rn=+1-202-544-0000;npdi=yes@xxx.yyy.biz;user=phone > > > > and > > tel:+1-202-533-1234;rn=+1-202-544-0000;npdi=yes > > > > will not be treated the same anyway since the scheme > > (sip:, tel:) does not > > match. > > The problem is that the same parameters would take > on different meanings depending on whether they > were present in a SIP vs. Tel Url. That is, they > would mean something in the tel URL and possibly > mean nothing in the SIP URL. > > > On a SIP URL containing a E.164 number, I do not see > > any problems in URL comp- > > arision if the parameters appear at the end (R-URI > > parameters). That is, > > given a SIP URL: > > > sip:+1-202-533-1234@xxx.yyy.biz;user=phone;rn=+1-202-544-0000;npdi=yes > > > > the normal URL matching rules would apply; i.e. the > > scheme has to match, the > > user part has to match, the domain has to match, and > > the parameters have to > > match. SIP entities that do not know anything about > > the parameters "npdi" > > and "rn" can still match the name of the parameter > > ("npdi", "rn") and the > > octets that appear as the value of these parameters. > > My original argument for having these parameters > as part of the user part is that they really do > reflect attributes of the "user" and not of the > SIP URL as a whole. At least the original parameters > did. With the new LNP stuff, this gets a little > trickier. > > There is also an argument for allowing the tel: URI > stuff to evolve independently of the SIP URL > specification. (Admittedly this is weaker, but this > is where the namespace collision stuff comes into > play) > > > Regards, > > > > - vijay > > -- > > Vijay K. Gurbani > > vkg@{lucent.com,research.bell-labs.com,acm.org} > > Internet Software and eServices Group > > Lucent Technologies/Bell Labs Innovations, 2000 > > Lucent Lane, Rm 6G-440 > > Naperville, Illinois 60566 Voice: +1 630 224 > > 0216 Fax: +1 630 713 0184 > > > > /sean > > ===== > Sean Olson > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 16:24:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06346 for ; Thu, 24 Jan 2002 16:24:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24327 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 16:24:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23434; Thu, 24 Jan 2002 16:07:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23403 for ; Thu, 24 Jan 2002 16:07:54 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05972 for ; Thu, 24 Jan 2002 16:07:49 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0OL5Vm2029749 for ; Thu, 24 Jan 2002 16:05:31 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Jan 2002 16:07:22 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9D8@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Subject: FW: [Sip] Loose Routing draft Date: Thu, 24 Jan 2002 16:07:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Resend - it looks like mail issues ate my first attempt. Apologies if this appears twice. -----Original Message----- > >> I would go one step further, and at least discourage > >> people from > >> loose-routing _subsequent_ requests (e.g. > >> re-INVIVEs). > > > >I see no reason to do this. Loose routing is all > >about local policy. As long as the strict > >route is honored, it shouldn't matter what happens > >in subsequent requests. > > Especially in cases, where you some element keeps > session state it should get also e.g. the BYE > concerning this session, in order to release the > resources. If a proxy before is allowed to just > modify the Request-URI (which has been recorded > earlier in Record-Route), it cannot be totally > sure anymore. > This is way, we cannot claim the loose-routing > to be 100% backwards compatible, if such things are > possible. The restrictions on the loose route policies are intended to make sure that any resource listed on a route set gets visited - it does not give a proxy license to say the request doesn't really need to visit the rest of the Route stack. It does allow other things to be visited along the way. That said, here's an example of the kind of thing that's concerning you (let me know if I misunderstood where you were going). Consider this BYE with a Route header established by Record-Route in a previous INVITE: (sent to p1) BYE sip:res@p1 Route , Assume p1 has a policy of popping the topmost route header into the reqeust-URI, but then sending the request off to some third place, (sent to p3) BYE sip:res@p2 Route Now if p3 has a policy to just rewrite the request-URI and sent things along to whatever was indicated in the topmost route, it might emit (sent to B) BYE sip:newres@elsewhere Route p2 never sees the request - this is bad. It turns out that nothing is special about this being a subsequent request - you can construct the same failure for initial requests. I can propose a restriction that plugs this hole, but that falls into treating a symptom instead of treating the problem. What the looseroute text needs to reflect is that a hop only exercises a non-strict-route policy when it knows what policy of the next hop is. If it doesn't have that knowledge, an element needs to strict route. So, p1 above would not send a request formatted as it is to a p3 that it didn't expect to send the request to what the Request-URI explicitly identified. So, how would p1 know to expect that? How does p1 know about such a p3 in the first place? Some administrative policy gave p1 the information about the existance of p3 - through protocol or configuration. The thing providing that configuration must have some knowledge of what p3 is expected to do. RjS > > I have the feeling, that we have to: > > 1) be able to distinguish whether a Route > header has been preloaded or not > e.g. we could introduce a new Route parameter, > informing about "preloaded" Wouldn't help (as above) > > 2) maybe even restrict the loose-routing in > preloaded case so much, that we can ensure that > every request passes the proxies, which > had record-routed. This is the real goal, whether the request is initial or within the route-set of an established dialog. > > If we make the difference between pre-loaded and > not pre-loaded (instead of between first and > sub-sequest requests), we still can have a (limited) > loose routing possibility in subsequent requests. > > cheers > Bernie > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 16:51:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07180 for ; Thu, 24 Jan 2002 16:51:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA26016 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 16:51:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24914; Thu, 24 Jan 2002 16:30:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24864 for ; Thu, 24 Jan 2002 16:30:13 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06547 for ; Thu, 24 Jan 2002 16:30:09 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g0OLTRn20885; Thu, 24 Jan 2002 13:29:32 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT07860; Thu, 24 Jan 2002 13:28:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA19664; Thu, 24 Jan 2002 13:29:28 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15440.31928.305274.598959@thomasm-u1.cisco.com> Date: Thu, 24 Jan 2002 13:29:28 -0800 (PST) To: Jonathan Rosenberg Cc: Mukesh R Shah , sip@ietf.org Subject: Re: [Sip] Regarding Encrytion of SIP messages In-Reply-To: <3C5067E0.746DF3D0@dynamicsoft.com> References: <007801c1a4a9$5eb05fd0$3c116f0a@HJNTNI108931> <3C5067E0.746DF3D0@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > RFC2543 supported PGP, but this has been deprecated in bis. > > Instead S/MIME will exist for the purposes of encryption. There will be > a good amount of detail on S/MIME in the forthcoming bis-06. There hasn't been any list discussion of this. I for one don't support its inclusion. 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 daemon@ns.ietf.org Thu Jan 24 17:03:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07580 for ; Thu, 24 Jan 2002 17:03:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27162 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 17:03:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25635; Thu, 24 Jan 2002 16:41:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25607 for ; Thu, 24 Jan 2002 16:41:24 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06804 for ; Thu, 24 Jan 2002 16:41:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.101]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OLfNGe029866; Thu, 24 Jan 2002 16:41:24 -0500 (EST) Message-ID: <3C507F5A.334A705D@dynamicsoft.com> Date: Thu, 24 Jan 2002 16:40:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Flemming Andreasen , Dean Willis , sip@ietf.org References: <15440.24661.363789.543940@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] calling number blocking at sip/isup gateway Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > Flemming Andreasen writes: > > > > in this example, the sip/isup gw will use one of its own phone > numbers as > > > the calling party number and that number needs privacy, not the > original > > > from uri sip:jdoe@foo.com. > > > > > Fine - just use the gw number instead then. > > but my proxy that would need to insert the Remote-Party-ID on behalf of > the UA, doesn't know what the gw number will be. > > > Nothing since there is no such requirement. In fact, if you have > requested > > privacy, you are almost guaranteed that the two will be different. > > i'm talkigng about the case where the UA doesn't understand the privacy > stuff (like no UA that i have seen doesn't) and i have to in the proxy > indicate the privacy requirement to the isup gw. then the from field > will include the real calling party number and the addr-spec in the > Remote-Party-ID has no function. Juha, I think what makes your problem more complex is that you have a UA that has asked for privacy, but has inserted a valid From header anyway. Normally, if the caller wanted anonymity, they would insert a From field with value anonymous (and a bogus URL). If nothing else happens (i.e., no proxies insert R-P-ID), everything is fine. If a proxy does insert an R-P-ID, which is needed to provide services and other functions, it has to strip it at the edge of the trust boundary, and that is the purpose of the privacy param. Now, in your case, here is what I would do: 1. the UA inserts its own ID in the From field 2. proxy determines that the user has privacy features. So, it acts as a B2BUA. It launches a new INVITE, different in that the From field now indicates anonymous. An R-P-ID header is present, with privacy indicated. If the next hop is not trusted, it is stripped. If it is, it is passed on to the edge of the trust network. 3. If the GW is within the trust boundary, it will see from R-P-ID that privacy is required, so it can set the ISUP flag appropriately. The URL in the R-P-ID can contain a telephone number for the user, if the proxy had one to put in, otherwise, the gateway will likely put in its own number. 4. If the GW is outside the trust boundary, From indicates anonymous, so the flag is set in the ISUP. However, there will be no phone number to deliver, so that gateway will need to use its own. That is the penalty for being outside the trust boundary. This process is not different for ISUP termination or SIP termination, as it should be. The cost of the B2BUA is because of your UA. Even rfc2543 says to use Anonymous in the From field if anonymity is required... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 17:14:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07948 for ; Thu, 24 Jan 2002 17:14:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27862 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 17:14:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26055; Thu, 24 Jan 2002 16:51:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26028 for ; Thu, 24 Jan 2002 16:51:45 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07208 for ; Thu, 24 Jan 2002 16:51:41 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.101]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0OLpqGe029887; Thu, 24 Jan 2002 16:51:52 -0500 (EST) Message-ID: <3C5081CF.FB739EB9@dynamicsoft.com> Date: Thu, 24 Jan 2002 16:51:11 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Mukesh R Shah , sip@ietf.org Subject: Re: [Sip] Regarding Encrytion of SIP messages References: <15440.31928.305274.598959@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Jonathan Rosenberg writes: > > RFC2543 supported PGP, but this has been deprecated in bis. > > > > Instead S/MIME will exist for the purposes of encryption. There will > be > > a good amount of detail on S/MIME in the forthcoming bis-06. > > There hasn't been any list discussion of this. > > I for one don't support its inclusion. Well, it has the benefit of being "for free". You can already do it today, since SIP carries MIME anyway. All we are doing is making people aware of that, and saying what is needed in order for it to work properly. What is your particular objection? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 18:03:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09084 for ; Thu, 24 Jan 2002 18:03:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00631 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 18:03:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28473; Thu, 24 Jan 2002 17:28:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28444 for ; Thu, 24 Jan 2002 17:28:20 -0500 (EST) Received: from revere.sonusnet.com (mail.sonusnet.com [208.45.178.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08331 for ; Thu, 24 Jan 2002 17:28:15 -0500 (EST) Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53]) by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0OMRXH25059; Thu, 24 Jan 2002 17:27:33 -0500 (EST) Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 17:27:34 -0500 Message-ID: <594A6AF62343D511B4750060CF20BAF3B92A7F@sonusdc5.sonusnet.com> From: "Holdrege, Matt" To: "'sip@ietf.org'" , "'huitema@windows.microsoft.com'" Date: Thu, 24 Jan 2002 17:27:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [Sipping] calling number blocking at sip/isup gateway Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org At 10:01 AM 1/24/2002, Christian Huitema wrote: >The mix of the four makes for an unsavory soup. In the privacy draft, >the law enforcement requirement can only be met by letting a proxy >insert a "Remote-Party-ID" header; but the moment you do that, you >enable every party down the chain to see and display that header. To >prevent abuse, the draft creates a "RPID-Privacy" header that the caller >should set to the appropriate value if it does not want the information >casually displayed. >Frankly, I am amazed by the naivety of the proposal. To make this work, >you then need a "chain of trust" between all the proxies; yet, we have >no mechanism to determine this level of trust. We also need to assume >that the information will not be displayed by the called UA regardless >of the value in the privacy field, which goes contrary to what we see >with e-mail, and also goes contrary to the obvious desire to fight spam. The mechanism we have is SIP-T, right? >Frankly, I don't find this privacy draft useful or adequate. It attempts >to comply with telephony-era regulations that have basically no meaning >in the Internet. In fact, we could probably meet these regulations by >having a much simpler solution that directly target ISUP compatibility: >a calling telephone number header, with a privacy tag, that gateways to >the telephone network could directly translate. Again, do we not have that with SIP-T? If SIP is used in a regulated network, then the proxies can be mandated to use SIP-T to preserve the regulation on caller-ID privacy. Of course, in a regulated network it might be required to have "chain of trust" between proxies. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 18:34:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09822 for ; Thu, 24 Jan 2002 18:34:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA02220 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 18:34:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00809; Thu, 24 Jan 2002 18:07:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00776 for ; Thu, 24 Jan 2002 18:07:34 -0500 (EST) Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09146 for ; Thu, 24 Jan 2002 18:07:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] RE: [Sipping] calling number blocking at sip/isup gateway Date: Thu, 24 Jan 2002 17:07:04 -0600 Message-ID: Thread-Topic: [Sip] RE: [Sipping] calling number blocking at sip/isup gateway Thread-Index: AcGlKhJ87W9urn9fTk6ZHXQBqSSPlAAAIQ/g From: "Chiou, Mark" To: "Holdrege, Matt" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA00777 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit SIP-T does not solve the problem. For my understanding, SIP-T is useful when 2 proxies server served as IWF are configured such that back-to-back are ISUPs. For example ISUP->PS-(SIP-T)-PS->ISUP. Otherwise, you want be able to map the cic number to the IP address correctly. Mark Chiou -----Original Message----- From: Holdrege, Matt [mailto:matt@sonusnet.com] Sent: Thursday, January 24, 2002 4:27 PM To: 'sip@ietf.org'; 'huitema@windows.microsoft.com' Subject: [Sip] RE: [Sipping] calling number blocking at sip/isup gateway At 10:01 AM 1/24/2002, Christian Huitema wrote: >The mix of the four makes for an unsavory soup. In the privacy draft, >the law enforcement requirement can only be met by letting a proxy >insert a "Remote-Party-ID" header; but the moment you do that, you >enable every party down the chain to see and display that header. To >prevent abuse, the draft creates a "RPID-Privacy" header that the caller >should set to the appropriate value if it does not want the information >casually displayed. >Frankly, I am amazed by the naivety of the proposal. To make this work, >you then need a "chain of trust" between all the proxies; yet, we have >no mechanism to determine this level of trust. We also need to assume >that the information will not be displayed by the called UA regardless >of the value in the privacy field, which goes contrary to what we see >with e-mail, and also goes contrary to the obvious desire to fight spam. The mechanism we have is SIP-T, right? >Frankly, I don't find this privacy draft useful or adequate. It attempts >to comply with telephony-era regulations that have basically no meaning >in the Internet. In fact, we could probably meet these regulations by >having a much simpler solution that directly target ISUP compatibility: >a calling telephone number header, with a privacy tag, that gateways to >the telephone network could directly translate. Again, do we not have that with SIP-T? If SIP is used in a regulated network, then the proxies can be mandated to use SIP-T to preserve the regulation on caller-ID privacy. Of course, in a regulated network it might be required to have "chain of trust" between proxies. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 20:24:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11283 for ; Thu, 24 Jan 2002 20:24:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA06183 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 20:24:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05050; Thu, 24 Jan 2002 19:56:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04945 for ; Thu, 24 Jan 2002 19:56:22 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10908 for ; Thu, 24 Jan 2002 19:56:19 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0P0tad06278; Thu, 24 Jan 2002 16:55:43 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT13181; Thu, 24 Jan 2002 16:55:00 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA19670; Thu, 24 Jan 2002 16:55:30 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15440.44290.633617.342558@thomasm-u1.cisco.com> Date: Thu, 24 Jan 2002 16:55:30 -0800 (PST) To: Jonathan Rosenberg Cc: Michael Thomas , Mukesh R Shah , sip@ietf.org Subject: Re: [Sip] Regarding Encrytion of SIP messages In-Reply-To: <3C5081CF.FB739EB9@dynamicsoft.com> References: <15440.31928.305274.598959@thomasm-u1.cisco.com> <3C5081CF.FB739EB9@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > > > Michael Thomas wrote: > > > > Jonathan Rosenberg writes: > > > RFC2543 supported PGP, but this has been deprecated in bis. > > > > > > Instead S/MIME will exist for the purposes of encryption. There will > > be > > > a good amount of detail on S/MIME in the forthcoming bis-06. > > > > There hasn't been any list discussion of this. > > > > I for one don't support its inclusion. > > Well, it has the benefit of being "for free". You can already do it > today, since SIP carries MIME anyway. All we are doing is making people > aware of that, and saying what is needed in order for it to work > properly. > > What is your particular objection? Not having seen the actual draft, it's hard to enumerate specific objections, but I'm mainly concerned about the law of unintended consequences. In particular, if SMIME make sense for other kinds of protected delivery (say, UAC/Proxy) later, does the bis-specified usage make that difficult/impossible? I'm also concerned about semantics and addressing and what happens when you might be tempted to repeat SIP headers inside and outside the MIME attachment. Also: I frankly don't think the e2e crypto is all that compelling at this point. Almost nobody implemented the PGP stuff, and I doubt that a change of format in the form of SMIME -- which has probably less penetration in mail than PGP -- will help that at all. It would be far more prudent to say nothing and keep our options open. However, this may be an excellent thing to put in an experimental RFC to see how it goes. 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 daemon@ns.ietf.org Thu Jan 24 21:47:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13478 for ; Thu, 24 Jan 2002 21:47:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA09443 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 21:47:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08550; Thu, 24 Jan 2002 21:27:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08519 for ; Thu, 24 Jan 2002 21:27:32 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12275 for ; Thu, 24 Jan 2002 21:27:28 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.101]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0P2RbGe000545; Thu, 24 Jan 2002 21:27:37 -0500 (EST) Message-ID: <3C50C26F.6FE0B390@dynamicsoft.com> Date: Thu, 24 Jan 2002 21:26:55 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: SIP Mailing List Subject: Re: [Sip] Re: Unify draft and 1-of-N References: <3C506D88.35D936A2@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Terry L Anderson wrote: > > Perhaps my confusion is simply that the behavior of each party in 5.1 is > not > carefully specified. > I read it as BOTH caller and callee send ALL codecs supported (even if > restricted to 1 of N) in first exchange. No, that wasn't the intent. Sorry if thats not clear. > If so and the 2nd INVITE is > optional > at the choice of caller then here's the problem: > > caller supports M of N simultaneously, callee is restricted to 1 of N > > caller sends: 0 4 8 15 97 on m line (all it can support but can only > support 2 > simultaneously) > > callee can support 0 and 15 but only 1 simultaneously, thinking that the > new > mechanism is in use (that caller MAY support only 1 of N) callee returns > 0 15 > on m line of 200 OK (or was callee supposed to choose only one and > indicate > the rest using simcap if callee can support only 1 of N, rather than > "ALL of > the codecs supported by the UA, even if they cannot be supported > simultaneously" as caller did?) In this case, the callee returns only one codec, since it can only do one. In parallel, it ought to use simcap in the 2xx to indicate its other codec capabilities. This way, if A wants, it can re-invite with two codecs, rather than just one. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 24 21:47:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13494 for ; Thu, 24 Jan 2002 21:47:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA09457 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 21:48:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08197; Thu, 24 Jan 2002 21:17:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA08168 for ; Thu, 24 Jan 2002 21:17:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12065 for ; Thu, 24 Jan 2002 21:17:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.101]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0P2H6Ge000532; Thu, 24 Jan 2002 21:17:06 -0500 (EST) Message-ID: <3C50BFF8.42CDF706@dynamicsoft.com> Date: Thu, 24 Jan 2002 21:16:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis CC: "Henning G. Schulzrinne" , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <200201222056.g0MKutB07305@valen.greycouncil.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis wrote: > > Dial "7" to reach housekeeping . . . > > It's the old local-versus-home services question. Yup. OK, here is the latest thought. We can't specify what to put, or not to put, in the URI. A UA should be able to implement a UI however it likes to make a decision about what the user meant. All we can do, is to give guidelines about what the URLs mean. Specifically, we should discuss the following: 1. when the user enters unqualified data, you can build a sip url or a tel url, and the sip url can be at a variety of domains (home or visited, for example) 2. a SIP URL means that you wish for the LHS to be interpreted at the domain in the RHS. So, if a user is visiting, this means that if the RHS is their home network, the home proxy would interpret it. Thats useful for things like group lists, speed dials, etc. which are in the home domain. You can also put a SIP URL with a domain in the RHS that is the visited domain, and then its interpreted there. For exmaple "touch 7 for housekeeping" could be sip:7@visiteddomain.com. 3. a tel URL doesn't specify who should interpret it. Each domain that receives the request, as it is forwarded, would have the ability to assign meaning to it. For example, tel:7 could be interpreted by the visited domain as "housekeeping", but if its not a number it knows, it could also do nothing with it. A discussion like that should provide implementors with sufficient guidance about what URL to put in there. NOW, the big problem remains, is that tel URL support is not mandatory in proxies, so if a UA decides to do (3), they are SOL. I am ready to simply say that proxies need to support the tel URL.... Here's an interesting question. How does "dial 7 for housekeeping" interact with loose routing? Presumably, when I'm visiting, I will have a loose route set to deliver the initial INVITE to my home domain. Lets say I dial 7, and this results in a tel:7 URL. That INVITE would look like: INVITE tel:7 SIP/2.0 Route: sip:homedomain.com THis goes to the hotel proxy, which rewrites tel:7 to sip:housekeeping@hotel.com, but also obeys the route, sending it there (it better not rewrite the r-uri): INVITE sip:housekeeping@hotel.com SIP/2.0 my home proxy does its outbound features, and sends it right back to the hotel proxy, which connects it to housekeeping. So, looks like things work, as long as the visited proxy does the right thing (rewrite the tel URL, pop the top route, use it, but don't rewrite the r-uri). -Jonathan R. > > I would argue that if I really want home services, I should explicitly > qualify the URL to indicate that I wanted it evaluated only in my home > domain. An unqualified URL should get evaluated the first place that > feels capabale of evaluating it . . . > > This makes things like 911, 411, and 112 services much easier to deal > with. > > -- > Dean > > On Friday 18 January 2002 10:55 am, you wrote: > > Dean Willis wrote: > > > No, because quite probably if you're visiting someone else's > > > corporate SIP phone, the gateway that will (perhaps MUST) be used > > > for PSTN termination is the local gateway, not the one back in your > > > home domain. > > > > Why is that? In most cases, I would certainly prefer to use my own > > phone service, rather than the hotel phone service, for example. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 22:27:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13956 for ; Thu, 24 Jan 2002 22:27:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA11273 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 22:27:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10318; Thu, 24 Jan 2002 22:02:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10287 for ; Thu, 24 Jan 2002 22:02:53 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13701 for ; Thu, 24 Jan 2002 22:02:49 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0P30Um2002150 for ; Thu, 24 Jan 2002 22:00:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 22:02:22 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9E1@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Thu, 24 Jan 2002 22:02:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #161 - called party usage of local outbound proxies wi th RR Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org bis-05 provides a recommendation of how to form a request-URI when placing a request containing a Route header using a default outbound proxy (DOP), especially when the UA placing the request is DNS unaware. That recommendation was to use the request-URI from the request that originated the dialog, and not remove the topmost route. That recommendation doesn't translate to the called party's side. If the called party needs to place a subsequent request and is similarly DNS challenged and uses a DOP, what does it use for a request-URI. The solution is that it uses the topmost Route header value in the request-URI and leaves that tompost Route header value in the request. It can then use the loop-avoidance algorithm to ensure it doesn't induce a false loop-detect at the location that value indicates. For consistancy, the recommended behavior for the calling party should be changed to match (open issue #284). RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 22:27:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13978 for ; Thu, 24 Jan 2002 22:27:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA11338 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 22:27:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10366; Thu, 24 Jan 2002 22:03:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10335 for ; Thu, 24 Jan 2002 22:03:13 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13706 for ; Thu, 24 Jan 2002 22:03:09 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0P30im2002159 for ; Thu, 24 Jan 2002 22:00:50 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Jan 2002 22:02:35 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9E2@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Thu, 24 Jan 2002 22:02:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #284: Forming the Request-URI when using a Default Out bound Proxy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This issue asks how to form a Request-URI in a request with Route headers when you are a UA that uses a default outbound proxy (DOP) such that you don't induce an incorrect loop-detection? This is the caller side of the same question asked for the callee side in open issue #161. This motivated the creation of the loop-avoidance algorithm in the looseroute proposal. Use of such an algorithm from either the perspective of a DOP using caller or callee addresses this issue. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 22:28:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13996 for ; Thu, 24 Jan 2002 22:28:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA11360 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 22:28:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10273; Thu, 24 Jan 2002 22:02:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10239 for ; Thu, 24 Jan 2002 22:02:38 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13690 for ; Thu, 24 Jan 2002 22:02:34 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0P30Fm2002144 for ; Thu, 24 Jan 2002 22:00:15 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 22:02:07 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9E0@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Thu, 24 Jan 2002 22:02:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #218: Ordering of maddr, route, domain processing in proxies Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The question in this issue is what order maddr, route, and domain should be considered in in determining where to send a request. Specifically, it asked if maddr should be inspected for a match before considering the contents of a Route header. This issue is subsumed by the loose routing question. As per issue #159, we have agreed that we want to allow loose routes, so the impact of these components becomes a local policy issue, subject to the restrictions of the meaning of the presence of an maddr in a SIP URI. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 22:34:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14985 for ; Thu, 24 Jan 2002 22:34:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA11963 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 22:34:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10409; Thu, 24 Jan 2002 22:03:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10379 for ; Thu, 24 Jan 2002 22:03:26 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13709 for ; Thu, 24 Jan 2002 22:03:21 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0P311m2002162 for ; Thu, 24 Jan 2002 22:01:02 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Jan 2002 22:02:51 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9E3@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Thu, 24 Jan 2002 22:02:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #368: Outbound proxy handling Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Issue: When a UA is configured to use a default outbound proxy (DOP), must it use the DOP for requests containing a Route header, or must it send the request to location indicated by the topmost Route header value? Discussion: Some UAs will not be capable of sending to the topmost Route. For example, doing so may require utilizing DNS, which some UAs will not implement. Such UAs need to use their DOP in this case, and to save implementation complexity may wish to just send every request to their DOP. On the other hand, when the UA is known to support DNS, or in environments where the UA can be assured of never seeing a name in the topmost route header, it would be advantageous to allow the DOP to choose whether or not to stay in the request path by utilizing Record-Route. So requiring all UAs using DOPs to send every request to the DOP is undesirable. Resolution: Under loose-routing, this becomes a policy decision for the UA. The UA will be handed its DOP and potentially a service route (basically, its loose routing policy) through an agreement with its service provider, establishing a policy coupling that obligates the service provider to have a compatible policy at the DOP. For UAs that are DNS capable, the policy may be to allow the DOP to back out of requests beyond the initial in the dialog by not record-routing. For UAs that are not DNS capable, the policy may be to use the topmost route if it is an explicit IP address, otherwise use the DOP. Alternately, the policy may be to send every request through the DOP whether or not it record-routed. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 22:47:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15270 for ; Thu, 24 Jan 2002 22:47:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA12155 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 22:47:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10227; Thu, 24 Jan 2002 22:02:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10195 for ; Thu, 24 Jan 2002 22:02:21 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13687 for ; Thu, 24 Jan 2002 22:02:17 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0P2xwm2002141 for ; Thu, 24 Jan 2002 21:59:58 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jan 2002 22:01:50 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E9DF@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Thu, 24 Jan 2002 22:01:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] open issues addressed by looseroute (Open issue #159) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Several open issues motivated the looseroute proposal: #159: Source routing (should we allow Route to be loose?) #161: Called party usage of local outbound proxies with RR #218: Ordering of maddr, route, domain processing in proxies #284: Forming the Request-URI when using a Default Outbound Proxy #368: Outbound proxy handling We have consensus on #159 that we should allow loose-routing and the loose route proposal specifies the mechanism. There hasn't been any comments indicating this is totally broken, and several comments of general support. We will proceed with the mechanism and refine it as we find places that need it. I'll be posting on the others individually, noting their resolution. RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 23:07:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15475 for ; Thu, 24 Jan 2002 23:07:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA13019 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 23:07:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12117; Thu, 24 Jan 2002 22:44:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12089 for ; Thu, 24 Jan 2002 22:44:50 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15231 for ; Thu, 24 Jan 2002 22:44:45 -0500 (EST) Received: from metroliner.cs.columbia.edu (IDENT:root@metroliner.cs.columbia.edu [128.59.19.252]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA21675; Thu, 24 Jan 2002 22:44:45 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by metroliner.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id g0P3ibd08314; Thu, 24 Jan 2002 22:44:38 -0500 Message-ID: <3C50D5D4.8F5A642C@cs.columbia.edu> Date: Thu, 24 Jan 2002 22:49:40 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <200201222056.g0MKutB07305@valen.greycouncil.com> <3C50BFF8.42CDF706@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree, except that "support" may simply mean to return 606 or 486. There is no obligation for every proxy to have a PSTN gateway. The user can then specify a suitable sip:@domain to place the call. I don't know if we need an explicit status code or Warning code for this case. I think a status code (URI scheme not supported) would be useful to make this case explicit. This may turn out to be useful for other things, such as IMPP. > to do (3), they are SOL. I am ready to simply say that proxies need to > support the tel URL.... > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 24 23:28:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15609 for ; Thu, 24 Jan 2002 23:28:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA13537 for sip-archive@odin.ietf.org; Thu, 24 Jan 2002 23:28:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12996; Thu, 24 Jan 2002 23:05:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12965 for ; Thu, 24 Jan 2002 23:05:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15455 for ; Thu, 24 Jan 2002 23:05:44 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.101]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0P45sGe000650; Thu, 24 Jan 2002 23:05:55 -0500 (EST) Message-ID: <3C50D97B.1992AD04@dynamicsoft.com> Date: Thu, 24 Jan 2002 23:05:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] Comments on "unify" draft - Part II References: <3C4BBA80.2C29337C@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > Here are some comments on unify. To make all issue easier to follow, I > will continue the numbering from where Rohan ended. > > Chapter 5.1 describes how the One-of-N codec negotiation takes place. > > My questions related to this: > > 7) If the same method, using two INVITEs, is used also for re-INVITEs in > the middle of the call (I assume it must be used also if the re-INVITE > contains a set of codecs and we need to pick one), how does it affect > the rule that "there must be no media cut while the codec > re-negoatiation takes place"? We do set the mode to "inactive" in the > first INVITE, so it would affect the media... Good question. You wouldn't use a=inactive here. You've already done an exchange, so presumably you know the codecs supported by the other side (because they included a bunch in the prior m line, or because of simcap, or because you sent OPTIONS in the dialog), so you would do the re-invite with the specific codecs you wanted. > > Chapter 5.4 describes how the early media takes place. > > My question(s) related to this: > > 8) How does the UAC know there will be early media, so it sets the mode > to "sendrecv", when 5.1 says it shall set the mode to "inactive" for the > first INVITE? It can do either; there is no requirement. Setting it to senrecv means that it might get early media. It needs to be prepared to receive media upon sending INVITE anyway, so there is no real change here. > > 9) Since 5.1 describes how the media negoatiation is done using two > INVITEs, how does the UAS suddenly know which codec to use (for the > early media) after receving only one INVITE? I think the One-of-N codec > problem affects also the early media, doesn't it? Not really. The UAS would send its list in the answer in a 183 (as opposed toa 200 OK for regular media), and then the UAC would update its offer in a COMET. Same SDP exchange as regular media, just a different set of sip messages. Thats the idea here, session exchanges through SDP are decoupled from dialog state. > > 10) IF the COMET (Rohan had some issues about that) is used to refuse > early media, why can't it also be used to accept early media - and > include the "final" codec for the early media? I am trying to define one general mechanism that solves all the problems. COMET isn't used to refuse or accept early media, its used to update session state, and that can be used to do anything. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 01:21:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17507 for ; Fri, 25 Jan 2002 01:21:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA27224 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 01:21:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16770; Fri, 25 Jan 2002 00:44:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16741 for ; Fri, 25 Jan 2002 00:44:52 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17114 for ; Fri, 25 Jan 2002 00:44:49 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0P5imw21535 for ; Fri, 25 Jan 2002 06:44:49 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0P5imr6013524; Fri, 25 Jan 2002 07:44:48 +0200 (EET) Message-ID: <3C50F0A8.2EFEF56D@lmf.ericsson.se> Date: Fri, 25 Jan 2002 07:44:08 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip@ietf.org Subject: Re: [Sip] 1-of-N codecs + inband DTMF References: <3C4FAC2F.542DD7BB@lmf.ericsson.se> <3C5024F0.F17F309A@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >I believe that for complex scenarios you will be better off using FID. >Simpler scenarios can be handled in the "unify" draff using vanilla SDP. I agree with you. However, I think there are currently MUCH more implementations doing inband DTMF than FID, so I just wanted to bring up this specific case, to make sure everyone is aware of it... Regards, Christer Holmberg Ericsson Finland > > Regards, > > Gonzalo > > Christer Holmberg wrote: > > > > Hi, > > > > This is not directly related to the unify draft, but to the "1-of-N > > codecs" mechanism in general. > > > > Assume that we want to also use inband DTMF, according to RFC 2833. So, > > since the DTMF from a SDP point of view now is a separate codec, in this > > case the final codec selection would be 2-of-N codecs, because I don't > > think anyone wants to send a re-INVITE everytime an inband DTMF is to be > > sent... > > > > Do you think this special case should be mentioned somewhere in the > > text? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 01:22:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17529 for ; Fri, 25 Jan 2002 01:22:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA27255 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 01:22:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16883; Fri, 25 Jan 2002 00:51:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16852 for ; Fri, 25 Jan 2002 00:51:31 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17202 for ; Fri, 25 Jan 2002 00:51:29 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.101]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0P5p6Ge000738; Fri, 25 Jan 2002 00:51:06 -0500 (EST) Message-ID: <3C50F223.26B1FF68@dynamicsoft.com> Date: Fri, 25 Jan 2002 00:50:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C50D5D4.8F5A642C@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > I agree, except that "support" may simply mean to return 606 or 486. That won't help, unless we mandate that clients retry with a SIP URL. > There is no obligation for every proxy to have a PSTN gateway. It has nothing to do with PSTN; consider Dean's "7 for housekeeping scenario", where the UA inserts tel:7. > The user > can then specify a suitable sip:@domain to place the call. The user, or the UA? This seems a burden for the user. I think they will view it as a system failure if they type something into their SIP phone and it never works, because their proxy doesn't support tel URL. > I don't know > if we need an explicit status code or Warning code for this case. I > think a status code (URI scheme not supported) would be useful to make > this case explicit. This may turn out to be useful for other things, > such as IMPP. Sounds here like you are proposing that the UA retry with a SIP URL this time. Is it better for the proxy to support tel URL, so it succeeds the first time, or for the UA to have to try tel, fail, then try SIP, and have to figure out what domain to put in the SIP URL? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 01:27:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17574 for ; Fri, 25 Jan 2002 01:27:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA27413 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 01:27:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16644; Fri, 25 Jan 2002 00:42:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA16608 for ; Fri, 25 Jan 2002 00:42:41 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17088 for ; Fri, 25 Jan 2002 00:42:38 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0P5gTIB005726; Fri, 25 Jan 2002 06:42:29 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0P5gTr6013301; Fri, 25 Jan 2002 07:42:29 +0200 (EET) Message-ID: <3C50F01D.4DC43E01@lmf.ericsson.se> Date: Fri, 25 Jan 2002 07:41:49 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Vijay Gurbani , sip@ietf.org Subject: Re: [Sip] Open Issue #144: Branch ID + isCancel() as transactionID References: <3C4FCB84.CE78303@lmf.ericsson.se> <3C5067A8.679DEBC7@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>2. Message merging >> >>Until now, the branch id was used by an UAS to check if a received >>INVITE message was a re-transmit of a previous INVITE message, or the >>same INVITE but which has taken a DIFFERENT route, since the "old" >>transaction identifiers (To, From, Call-ID and CSeq) were the same in >>both cases. I guess the "old" identifiers, or at least parts (maybe the >>Call-ID and CSeq are enough?) of them, still have to be used for this >>purpose, don't they? > >A merged request would appear as a different transaction, with a >different branch ID. If the proxy cares to determine that this is a >merge (generally not necessary), it could look at to/from/call-id/cseq >if it wants, but there is no reason as far as I can tell. So, since the INVITE in this case is a DIFFERENT transaction (previously it was part of the SAME transaction, even if the branch id was different), should it be treated as a merge in the first place? If it's treated as a different transaction, isn't there a protocol error, since it uses the SAME CSeq value as another transaction? So, instead of checking if the INVITE is a merge, the UAS could simply return 400? >Proxies do not handle merging, only UAs. I was talking about UAs. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 01:30:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17612 for ; Fri, 25 Jan 2002 01:30:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA27872 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 01:30:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21657; Fri, 25 Jan 2002 01:08:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21598 for ; Fri, 25 Jan 2002 01:08:12 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17433 for ; Fri, 25 Jan 2002 01:08:09 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0P685IB008732; Fri, 25 Jan 2002 07:08:05 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0P684r6015474; Fri, 25 Jan 2002 08:08:04 +0200 (EET) Message-ID: <3C50F61D.EDAB03C9@lmf.ericsson.se> Date: Fri, 25 Jan 2002 08:07:25 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [Sip] Comments on "unify" draft - Part II References: <3C4BBA80.2C29337C@lmf.ericsson.se> <3C50D97B.1992AD04@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>7) If the same method, using two INVITEs, is used also for re-INVITEs in >>the middle of the call (I assume it must be used also if the re-INVITE >>contains a set of codecs and we need to pick one), how does it affect >>the rule that "there must be no media cut while the codec >>re-negoatiation takes place"? We do set the mode to "inactive" in the >>first INVITE, so it would affect the media... > >Good question. You wouldn't use a=inactive here. You've already done an >exchange, so presumably you know the codecs supported by the other side >(because they included a bunch in the prior m line, or because of >simcap, or because you sent OPTIONS in the dialog), so you would do the >re-invite with the specific codecs you wanted. Would it be worth putting a few words in the text about this, saying that a client SHOULD use one of the codecs it received by the other side when the call was established, because then only a single re-INVITE is needed? And, IF one wants to include a NEW set of codecs in the re-INVITE, one should be aware that TWO re-INVITEs are needed, since a re-negoatiation must be done. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 01:37:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17675 for ; Fri, 25 Jan 2002 01:37:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28013 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 01:37:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27039; Fri, 25 Jan 2002 01:15:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26934 for ; Fri, 25 Jan 2002 01:15:48 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17478 for ; Fri, 25 Jan 2002 01:15:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.101]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0P6FmGe000758; Fri, 25 Jan 2002 01:15:49 -0500 (EST) Message-ID: <3C50F7EE.A46374E3@dynamicsoft.com> Date: Fri, 25 Jan 2002 01:15:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kristoffer Gronowski CC: sip@ietf.org Subject: Re: [Sip] Comments and suggestions to draft-ietf-sip-nat-01.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Kristoffer Gronowski wrote: > > Hi! We have implemented the draft on our SIP server and client and I > have some reflections and suggestions to propose. > > Section 3 "For INVITE transactions, the > client may need to retransmit its INVITE every 20 seconds or so, even > after receiving a provisional response, in order to keep the binding > open to receive the final response." > > Should a retransmit value smaller then 32 seconds (11 retransmissions) > be permitted? > This would encourage clients to send requests to often and possibly > flood the system! I doubt this will be a frequent need, since most calls are answered or aborted within 20s anyway. However, this requirement can be relaxed a little, in the sense that, it needs to retransmit the INVITE if no provisional responses are received after 20s. The resolution of the issue with Timer C is such that the UAS will send new provisional responses to refresh the timer, this has the benefit of also keeping the nat binding alive. If you want to increase this 20s value above 32s, you run the risk of total call failure. That is a penalty of using UDP; TCP is preferred for NAT traversal. > It might be OK to do it more often if a 2xx response is received. Huh? If a 2xx is received, you're done, there is no need to resend the INVITE. > > Section 4. Translate header is sent back to client. > Is this really necessary? The bottom Via contain both the white and > black IP addresses and ports? I am assuming that by "white" you mean the public address, and by "black" you mean the private one (or perhaps, vice a versa). THis is the first time I have heard such terms. This is a good point, though. As far as I can tell, the value in Translate will be the same as the rport/received in the top via, so it is redundant. I will remove it unless someone can think of a problem with that. > We have tried to solve the firewall problem with the same approach. > Since the majority of the firewalls has statful inspection. Then the > state can be kept alive with the same approach. The UA has to send a SIP > message frequently enough. A firewall can be seen as a symmetrical NAT > without the address translation part. That depends on the policy of the firewall. Some firewalls behave that way, others may block UDP entirely. > This makes it more difficult to > detect. One simple solution is that the UA lets the end user to specify > if behind FW or not. For a more complex UA the probing approach with > sending OPTIONS SIP message can be used. STUN describes a mechanism for detecting the presence of this kind of firewall. I think that will suffice. > > One of the biggest concerns is that the record routing in the proxy is > fairly expensive operation. A suggestion is to tag the contact with the > nat=sym parameter and only record route those requests. This will solve > both the tricky NAT's and stateful inspection firewalls! Thats fine. Its a local policy decision that can be made by the proxy. I can add mention of it. > > REGISTER sip:ua2@Y.com SIP/2.0 > From: sip:ua2@Y.com > To: sip:ua2@Y.com > Via: SIP/2.0/UDP 10.0.1.100;rport > Translate: sip:ua2@10.0.1.100:2234;nat=sym > Contact: sip:ua2@10.0.1.100:2234 > > SIP/2.0 200 OK > From: sip:ua2@Y.com > To: sip:ua2@Y.com > Via: SIP/2.0/UDP 10.0.1.100;rport=2397;received=77.2.3.88 > Contact: sip:ua2@77.2.3.88:2397;nat=sym > > To put the NAT parameter on the contact feels quite natural since it > describes the contacts property and routing essential information. I don't follow this. Why do that? The UA already knows its behind a symmetric NAT (it did tell the registrar). The registrar knows it too. What is gained by returning it in the contact of the registration response? > > Another recommendation should be to check all the final responses sent > from the server to the UA. The Via header black and white addresses > should be compared with the once that the UA is believed to have. This > is due to the fact that a NAT can change the used white port at given > times. The UA should detect this and refresh it's registration so that > other UA can find it! If UDP is in use, the registration refreshes frequently enough that you would notice there first, though. For TCP, the binding wouldn't change while the TCP connection is opened. Thus, I am not sure this really adds anything. > If the UA can handle presence the SUBSCRIBE SIP > messages have to be refreshed as well! I don't think so. Only the register needs to be refreshed. As long as its binding is maintained, the contact provided in the SUBSCRIBE is valid. If, however, the binding changes, then a refresh of SUBSCRIBE is needed. I can mention that. > > The last issue is if this draft should contain solutions for the IM and > presence extension so that they can handle NAT's? There is nothing specific that needs to be done for IM or presence. The issue you mention above for SUBSCRIBE will occur for all methods which establish dialogs. A general discussion for refreshing contacts in active dialogs, when the binding changes, will cover INVITE and SUBSCRIBE and anything else. Thanks for your comments, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 01:45:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17756 for ; Fri, 25 Jan 2002 01:45:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28251 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 01:45:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27319; Fri, 25 Jan 2002 01:24:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27294 for ; Fri, 25 Jan 2002 01:24:25 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17551 for ; Fri, 25 Jan 2002 01:24:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.101]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0P6OVGe000761; Fri, 25 Jan 2002 01:24:31 -0500 (EST) Message-ID: <3C50F9F9.1454981B@dynamicsoft.com> Date: Fri, 25 Jan 2002 01:23:53 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Vijay Gurbani , sip@ietf.org Subject: Re: [Sip] Open Issue #144: Branch ID + isCancel() as transactionID References: <3C4FCB84.CE78303@lmf.ericsson.se> <3C5067A8.679DEBC7@dynamicsoft.com> <3C50F01D.4DC43E01@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > >>2. Message merging > >> > >>Until now, the branch id was used by an UAS to check if a received > >>INVITE message was a re-transmit of a previous INVITE message, or the > >>same INVITE but which has taken a DIFFERENT route, since the "old" > >>transaction identifiers (To, From, Call-ID and CSeq) were the same in > >>both cases. I guess the "old" identifiers, or at least parts (maybe the > >>Call-ID and CSeq are enough?) of them, still have to be used for this > >>purpose, don't they? > > > >A merged request would appear as a different transaction, with a > >different branch ID. If the proxy cares to determine that this is a > >merge (generally not necessary), it could look at to/from/call-id/cseq > >if it wants, but there is no reason as far as I can tell. > > So, since the INVITE in this case is a DIFFERENT transaction (previously > it was part of the SAME transaction, even if the branch id was > different), should it be treated as a merge in the first place? If it's > treated as a different transaction, isn't there a protocol error, since > it uses the SAME CSeq value as another transaction? So, instead of > checking if the INVITE is a merge, the UAS could simply return 400? Christer, please read bis-05, Section 17. There is now a clear and concise definition of transaction. It is scoped between a client and a server transaction in two elements. Each hop between a pair of stateful proxies is a separate transaction. CSeq is used as an ordering mechanism of requests between UAs, within the scope of a dialog. A dialog is identified by Call-iD, to/from. Thus, there is no protocol error when a proxy or a UA receives a request with the same cseq but is a different tnrasaction. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 01:50:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17804 for ; Fri, 25 Jan 2002 01:50:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28366 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 01:50:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27385; Fri, 25 Jan 2002 01:26:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27354 for ; Fri, 25 Jan 2002 01:26:10 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17557 for ; Fri, 25 Jan 2002 01:26:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.101]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0P6QDGe000765; Fri, 25 Jan 2002 01:26:14 -0500 (EST) Message-ID: <3C50FA5F.384C8B7F@dynamicsoft.com> Date: Fri, 25 Jan 2002 01:25:35 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] Comments on "unify" draft - Part II References: <3C50F61D.EDAB03C9@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > >>7) If the same method, using two INVITEs, is used also for re-INVITEs > in > >>the middle of the call (I assume it must be used also if the re-INVITE > >>contains a set of codecs and we need to pick one), how does it affect > >>the rule that "there must be no media cut while the codec > >>re-negoatiation takes place"? We do set the mode to "inactive" in the > >>first INVITE, so it would affect the media... > > > >Good question. You wouldn't use a=inactive here. You've already done an > >exchange, so presumably you know the codecs supported by the other side > >(because they included a bunch in the prior m line, or because of > >simcap, or because you sent OPTIONS in the dialog), so you would do the > >re-invite with the specific codecs you wanted. > > Would it be worth putting a few words in the text about this, saying > that a client SHOULD use one of the codecs it received by the other side > when the call was established, because then only a single re-INVITE is > needed? And, IF one wants to include a NEW set of codecs in the > re-INVITE, one should be aware that TWO re-INVITEs are needed, since a > re-negoatiation must be done. I think it is premature to discuss adding wording to this document to clarify things. This document is not meant to proceed as a work item. Rather, it is meant to solicit opinions on whether the proposed direction is correct. Much needs to be done to distill concise semantics from the proposal. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 02:11:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26252 for ; Fri, 25 Jan 2002 02:11:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA29328 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 02:11:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28247; Fri, 25 Jan 2002 01:45:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28216 for ; Fri, 25 Jan 2002 01:45:46 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17747 for ; Fri, 25 Jan 2002 01:45:44 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0P6jgw13431; Fri, 25 Jan 2002 07:45:42 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0P6jgr6017743; Fri, 25 Jan 2002 08:45:42 +0200 (EET) Message-ID: <3C50FEEE.D0135F69@lmf.ericsson.se> Date: Fri, 25 Jan 2002 08:45:02 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Vijay Gurbani , sip@ietf.org Subject: Re: [Sip] Open Issue #144: Branch ID + isCancel() as transactionID References: <3C4FCB84.CE78303@lmf.ericsson.se> <3C5067A8.679DEBC7@dynamicsoft.com> <3C50F01D.4DC43E01@lmf.ericsson.se> <3C50F9F9.1454981B@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>>A merged request would appear as a different transaction, with a >>>different branch ID. If the proxy cares to determine that this is a >>>merge (generally not necessary), it could look at to/from/call-id/cseq >>>if it wants, but there is no reason as far as I can tell. >> >>So, since the INVITE in this case is a DIFFERENT transaction (previously >>it was part of the SAME transaction, even if the branch id was >>different), should it be treated as a merge in the first place? If it's >>treated as a different transaction, isn't there a protocol error, since >>it uses the SAME CSeq value as another transaction? So, instead of >>checking if the INVITE is a merge, the UAS could simply return 400? > >Christer, please read bis-05, Section 17. > >There is now a clear and concise definition of transaction. It is scoped >between a client and a server transaction in two elements. Each hop >between a pair of stateful proxies is a separate transaction. CSeq is >used as an ordering mechanism of requests between UAs, within the scope >of a dialog. A dialog is identified by Call-iD, to/from. > >Thus, there is no protocol error when a proxy or a UA receives a request >with the same cseq but is a different tnrasaction. So, in THEORY a UAC could now send two or more mid-call INFOs (or re-INVITEs etc), within a specific dialog, using the SAME CSeq, and the UAS would not treat it as an error, right? OR, does the UAS have to know if a received request is a merge (an initial INVITE, for example), in which case it's not an error using the same CSeq, or if a received request was sent by the UAC, in which case I think it IS an error using the same CSeq. Again, in both cases the requests are received within the same dialog. I don't want to continue this thread forever, but I just need a clarification. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 02:19:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26328 for ; Fri, 25 Jan 2002 02:19:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA29595 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 02:19:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28483; Fri, 25 Jan 2002 01:52:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28451 for ; Fri, 25 Jan 2002 01:52:46 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17824 for ; Fri, 25 Jan 2002 01:52:44 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0P6qfIB028504; Fri, 25 Jan 2002 07:52:41 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0P6qer6018184; Fri, 25 Jan 2002 08:52:40 +0200 (EET) Message-ID: <3C510090.BF1243D9@lmf.ericsson.se> Date: Fri, 25 Jan 2002 08:52:00 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Terry L Anderson , SIP Mailing List , gonzalo.camarillo@lmf.ericsson.se Subject: Re: [Sip] Re: Unify draft and 1-of-N References: <3C506D88.35D936A2@lucent.com> <3C50C26F.6FE0B390@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>Perhaps my confusion is simply that the behavior of each party in 5.1 is >>not carefully specified. >>I read it as BOTH caller and callee send ALL codecs supported (even if >>restricted to 1 of N) in first exchange. > >No, that wasn't the intent. Sorry if thats not clear. I guess I understood the text in the same way as Terry :) That's the reason I brought up the question about the inband DTMF (in another thread). I guess that's not an issue anymore... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 02:50:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26625 for ; Fri, 25 Jan 2002 02:50:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA00560 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 02:50:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA29749; Fri, 25 Jan 2002 02:23:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA29717 for ; Fri, 25 Jan 2002 02:23:30 -0500 (EST) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26376 for ; Fri, 25 Jan 2002 02:23:28 -0500 (EST) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id g0P7NTJ01378; Fri, 25 Jan 2002 02:23:30 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Open Issue #144: Branch ID + isCancel() as transactionID Date: Fri, 25 Jan 2002 02:26:03 -0500 Message-ID: <001a01c1a571$8c1f6600$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3C50FEEE.D0135F69@lmf.ericsson.se> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > So, in THEORY a UAC could now send two or > more mid-call INFOs (or re-INVITEs etc), > within a specific dialog, using the SAME > CSeq, and the UAS would not treat it as > an error, right? If a positive response was returned to the first request, a 482 should be returned to the other branched request. If a negative response was returned, the UA should analyze the request like the other branched request was not received. There are two main reasons to branch within a dialogue. 1) Allows a proxy to resubmit a request when a UAS or proxy didn't like something the proxy added. 2) Allows a proxy to resubmit a request under failure conditions using the bis-05 section 24 functionality. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 07:24:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00226 for ; Fri, 25 Jan 2002 07:24:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA11608 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 07:24:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10156; Fri, 25 Jan 2002 06:53:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10117 for ; Fri, 25 Jan 2002 06:53:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29524; Fri, 25 Jan 2002 06:53:29 -0500 (EST) Message-Id: <200201251153.GAA29524@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 25 Jan 2002 06:53:28 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-srv-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP: Locating SIP Servers Author(s) : H. Schulzrinne, J. Rosenberg Filename : draft-ietf-sip-srv-04.txt Pages : 14 Date : 24-Jan-02 The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP URI into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-srv-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-srv-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-srv-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020124145514.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-srv-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-srv-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020124145514.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 07:40:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00575 for ; Fri, 25 Jan 2002 07:40:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA12299 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 07:40:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10878; Fri, 25 Jan 2002 07:03:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA10730 for ; Fri, 25 Jan 2002 07:02:59 -0500 (EST) Received: from zctfs063.europe.nortel.com (h105s128a237n47.user.nortelnetworks.com [47.237.128.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29757; Fri, 25 Jan 2002 07:02:55 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0PC2KW23185; Fri, 25 Jan 2002 13:02:20 +0100 (MET) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0PC1uq12122; Fri, 25 Jan 2002 12:01:56 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 12:02:13 -0000 Message-ID: From: "Mark Watson" To: "'Christian Huitema'" , Juha Heinanen , Dean Willis Cc: sipping@ietf.org, "'Sip@ietf.org'" Date: Fri, 25 Jan 2002 12:02:10 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A598.1E5985C0" Subject: [Sip] RE: [Sipping] calling number blocking at sip/isup gateway Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A598.1E5985C0 Content-Type: text/plain I have to say I am amazed too. But by the idea that the privacy regulations we see in the PSTN/ISDN may not apply in the SIP world. These stem from technology-neutral Data Protection legislation which applies as much to SIP as to ISUP or TUP. Sure, in a model where there are no trust relationships, then if you want to keep something private you either (a) don't send it at all (b) encrypt so that only people you *do* trust can see it. It comes back to the trust model argument. I do think it likely though that there will be models where calls are routed between service providers on the basis of Service Level Agreements between those providers. If your SLA includes that the other provider agrees to provide certain QoS etc. for your subscriber's calls, it can also include provisions regarding trust of user identities etc. There are also reasons why the Service Providers may wish to exchange the identity/ies of the caller, but the caller may wish to remain anonymous to the called party. Mayby these Service Providers are incredibly naive ? Mayby they should be happy to rely on networks with which they have no SLA to deliver calls on behalf of their subscribers ? Mayby there is no market for better than best effort service ? Regards...Mark > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: 24 January 2002 18:01 > To: Juha Heinanen; Dean Willis > Cc: sipping@ietf.org > Subject: RE: [Sipping] calling number blocking at sip/isup gateway > > > > ok, i tried again and still can't figure out how my proxy > can tell to > a > > trusted sip/isup gw that the calling user doesn't want his/her phone > > number to be shown to the called pstn user. i would like to be able > to > > do something simple in the proxy, like adding a header > > > > Anonymity: from > > > > to the invite, but that kind of thing is not available. my > suggestion > > is that the authors of the privacy i-d and the sip-isup i-d > figure it > > out how to map isup Calling party indicator "Address presentation > > restricted" to/from sip. before that is done, i would not > vote going > > forward with either i-d. > > There is an obvious tension between four issues: > > - The fact that when an UA is under the user's control, the content of > the header fields can be set to arbitrary values, and that any header > field can be expected to be read by the final user; > - The legal requirement in many countries for "traceability", i.e. the > possibility for law enforcement to find the source of any phone call; > - The desire in many cases to place anonymous calls, i.e. without > disclosing the identity and/or the location of the caller (Think > "whistle blower"); > - The desire in even more cases to block anonymous calls (Think spam). > > The mix of the four makes for an unsavory soup. In the privacy draft, > the law enforcement requirement can only be met by letting a proxy > insert a "Remote-Party-ID" header; but the moment you do that, you > enable every party down the chain to see and display that header. To > prevent abuse, the draft creates a "RPID-Privacy" header that > the caller > should set to the appropriate value if it does not want the > information > casually displayed. > > Frankly, I am amazed by the naivety of the proposal. To make > this work, > you then need a "chain of trust" between all the proxies; yet, we have > no mechanism to determine this level of trust. We also need to assume > that the information will not be displayed by the called UA regardless > of the value in the privacy field, which goes contrary to what we see > with e-mail, and also goes contrary to the obvious desire to > fight spam. > > Frankly, I don't find this privacy draft useful or adequate. > It attempts > to comply with telephony-era regulations that have basically > no meaning > in the Internet. In fact, we could probably meet these regulations by > having a much simpler solution that directly target ISUP > compatibility: > a calling telephone number header, with a privacy tag, that > gateways to > the telephone network could directly translate. > > -- Christian Huitema > > _______________________________________________ > 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 > ------_=_NextPart_001_01C1A598.1E5985C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] calling number blocking at sip/isup = gateway

I have to say I am amazed too. But by the idea that = the privacy regulations we see in the PSTN/ISDN may not apply in the = SIP world. These stem from technology-neutral Data Protection = legislation which applies as much to SIP as to ISUP or TUP.

Sure, in a model where there are no trust = relationships, then if you want to keep something private you either = (a) don't send it at all (b) encrypt so that only people you *do* trust = can see it.

It comes back to the trust model argument.

I do think it likely though that there will be models = where calls are routed between service providers on the basis of = Service Level Agreements between those providers. If your SLA includes = that the other provider agrees to provide certain QoS etc. for your = subscriber's calls, it can also include provisions regarding trust of = user identities etc.

There are also reasons why the Service Providers may = wish to exchange the identity/ies of the caller, but the caller may = wish to remain anonymous to the called party.

Mayby these Service Providers are incredibly naive ? = Mayby they should be happy to rely on networks with which they have no = SLA to deliver calls on behalf of their subscribers ? Mayby there is no = market for better than best effort service ?

Regards...Mark

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
> Sent: 24 January 2002 18:01
> To: Juha Heinanen; Dean Willis
> Cc: sipping@ietf.org
> Subject: RE: [Sipping] calling number blocking = at sip/isup gateway
>
>
> > ok, i tried again and still can't figure = out how my proxy
> can tell to
> a
> > trusted sip/isup gw that the calling user = doesn't want his/her phone
> > number to be shown to the called pstn = user.  i would like to be able
> to
> > do something simple in the proxy, like = adding a header
> >
> > Anonymity: from
> >
> > to the invite, but that kind of thing is = not available.  my
> suggestion
> > is that the authors of the privacy i-d and = the sip-isup i-d
> figure it
> > out how to map isup Calling party = indicator "Address presentation
> > restricted" to/from sip.  before = that is done, i would not
> vote going
> > forward with either i-d.
>
> There is an obvious tension between four = issues:
>
> - The fact that when an UA is under the user's = control, the content of
> the header fields can be set to arbitrary = values, and that any header
> field can be expected to be read by the final = user;
> - The legal requirement in many countries for = "traceability", i.e. the
> possibility for law enforcement to find the = source of any phone call;
> - The desire in many cases to place anonymous = calls, i.e. without
> disclosing the identity and/or the location of = the caller (Think
> "whistle blower");
> - The desire in even more cases to block = anonymous calls (Think spam).
>
> The mix of the four makes for an unsavory soup. = In the privacy draft,
> the law enforcement requirement can only be met = by letting a proxy
> insert a "Remote-Party-ID" header; = but the moment you do that, you
> enable every party down the chain to see and = display that header. To
> prevent abuse, the draft creates a = "RPID-Privacy" header that
> the caller
> should set to the appropriate value if it does = not want the
> information
> casually displayed.
>
> Frankly, I am amazed by the naivety of the = proposal. To make
> this work,
> you then need a "chain of trust" = between all the proxies; yet, we have
> no mechanism to determine this level of trust. = We also need to assume
> that the information will not be displayed by = the called UA regardless
> of the value in the privacy field, which goes = contrary to what we see
> with e-mail, and also goes contrary to the = obvious desire to
> fight spam.
>
> Frankly, I don't find this privacy draft useful = or adequate.
> It attempts
> to comply with telephony-era regulations that = have basically
> no meaning
> in the Internet. In fact, we could probably = meet these regulations by
> having a much simpler solution that directly = target ISUP
> compatibility:
> a calling telephone number header, with a = privacy tag, that
> gateways to
> the telephone network could directly = translate.
>
> -- Christian Huitema
>
> = _______________________________________________
> 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
>

------_=_NextPart_001_01C1A598.1E5985C0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 09:01:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02880 for ; Fri, 25 Jan 2002 09:01:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA15689 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 09:02:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14546; Fri, 25 Jan 2002 08:32:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14514 for ; Fri, 25 Jan 2002 08:32:04 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01911 for ; Fri, 25 Jan 2002 08:32:00 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 3F2D51E0B1 for ; Fri, 25 Jan 2002 08:32:02 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA11111; Fri, 25 Jan 2002 08:31:59 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA87743; Fri, 25 Jan 2002 08:33:05 -0500 (EST) Date: Fri, 25 Jan 2002 08:33:05 -0500 (EST) Message-Id: <200201251333.IAA87743@fish.research.att.com> To: sip@ietf.org Subject: Re: [Sip] Re: Unify draft and 1-of-N Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm very concerned about the call flow shown in section 5.1 of the unify draft, which does codec negotiation through the use of a Re-INVITE. The main problem is the resulting post-pickup delay. When more than a few hundred milliseconds, it results in a failed call (from the user's view) and a completed billable call (from the provider's view). Not a happy situation, especially if it occurs on every call attempt. Retraining the users is hardly an option. The only way I see to resolve this is to delay the ringing until the re-INVITE, when the codec set is known and the extra roundtrips are not needed before the media path is established. And this leads to all the problems with the original two-stage invite. The much better solution is shown in the unify draft in section 5.5, figure 12, utilizing a COMET/UPDATE (message (5)) that picks the codec to use. I would really hate to see the re-INVITE of section 5.1 described in bis-06 because of not wanting to define the COMET/UPDATE method. Much better to state that codec negotiation is not suspported in bis, and requires an extension, and then not have to consider the backwards compatibility problems with UA's that do the immediate re-INVITE. Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 10:01:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04388 for ; Fri, 25 Jan 2002 10:01:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18624 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 10:01:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16781; Fri, 25 Jan 2002 09:29:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16750 for ; Fri, 25 Jan 2002 09:28:58 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03577 for ; Fri, 25 Jan 2002 09:28:54 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id D87774CEB4 for ; Fri, 25 Jan 2002 09:28:55 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA11921; Fri, 25 Jan 2002 09:28:52 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA73141; Fri, 25 Jan 2002 09:30:16 -0500 (EST) Date: Fri, 25 Jan 2002 09:30:16 -0500 (EST) Message-Id: <200201251430.JAA73141@fish.research.att.com> To: sip@ietf.org Subject: Re: [Sip] Comments on "unify" draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan wrote, in part: > > Offer/Counter-Offer/Answer is a much cleaner solution than a > > two-stage invite. > > I would still like to know in what ways an three-way exchange is > cleaner? It is a few messages shorter, for sure. However, it cannot do > anything the two two-pass cannot do, either functionally, or in terms of > latency. However, it adds complexity, since now we have two exchange > mechanisms, and we will need to worry about how this interacts with > 3pcc, how to signal which one is being used in which cases, and so on. > The proposal eliminates all of that. I agree that a pair of two-way exchanges can do everything that a three-way exchange can do, plus more. My comment above was that the three-way exchange was better than the two-stage invite, and I doubt there is any disagreement on that point. One way in which the pair of two-way exchanges is significantly better is that, in the 3-way exchange, the (UAS) response/counter-offer would need to assign ports for all supported media streams, and just hope that the UAC would not use most of them. It is much better that the fourth SDP (the second answer) give only ports for the media that will be used. Jonathan also wrote: > My main concern, and I am surprised its not yours as well, is timely > completion of bis for 3gpp. To do that, we require parallelism. I would > very much like to last call bis-06 as issued, and we could do that > shortly if this stuff stays out. In parallel with the last call period, > and iesg review, we can refine UPDATE/COMET, as this will take some > time. Agree completely with the goal, and the concern. But I guess I am less convinced that we can get three new I-Ds (one defining COMET/UPDATE, second for manyfolks, third for codec negotiation) through to RFCs in almost zero time. Past experience (which I know does not indicate future results) is 30+ months. From a 3GPP view, is it better to have bis and not the other three? Or all combined, but one or two months later? From what I recall of TS24.228, the unify draft is already wrecking major havoc. Could someone (Rakesh?) try posting a reasonable schedule that meets the needed deadlines? Bill Marshall wtm@research.att.com -----original message----- Date: Thu, 24 Jan 2002 15:34:44 -0500 From: Jonathan Rosenberg To: William Marshall Cc: sip@ietf.org Subject: Re: [Sip] Comments on "unify" draft William Marshall wrote: > > Jonathan wrote: > > > > In general, it would be helpful to get general feedback of the form > > "seems like the right direction". Particularly, the main thing I need > > feedback on ASAP is the proposal to pretty much keep this all out of > > bis. The only thing in bis would be some generalized statement of when > > > you can see offers and answers, so that we can separate the > > EM/manyfolks/herfp solutions from bis. Granted, this stuff still needs > > > to be on the fast track for 3g, but I want to get it separated from > bis. > > > > First, I definitely agree this aspect should be decided quickly. > > I may be in the minority, but I think that a problem in 2543 should > be fixed in the next version of the RFC, and that HERFP qualifies > as a bug in 2543. It seems wrong to have a "supported:" tag defined > for a fix for a bug. This tag will be present irregardless of where this text lives. This is needed to enable compatibility with existing sip implementations, most of which follow one of the earlier bis drafts. Note that even though 100rel is folded into bis, it still requires usage of the Supported header. > > The main argument against this that I see is one of backwards > compatability. But everyone seems to agree that a UA or proxy > written to conform to 2543 is nearly useless - so the question > seems to be one of backwards compatability to what? To existing implementations that are deployed, or are about to be deployed and cannot be quickly changed. That is all that matters. According to formal IETF process, we have no requirement at all for backwards compatibility as far as I know; we are trying to maintain as much as possible to preserve continued operation of the protocol. > Do we really > need to maintain backwards comatability to a I-D, defined as only > a "Work in Progress"? With the definition of Route and Record-Route > in bis, we've already given up backwards compatability with a > pure-2543 proxy, and a fix for HERFP does not make the situation > any worse. See above, Bill. There is no UA I know of in any deployed situation that is purely 2543 compliant, since the RR processing there was simply underspecified. Most are following one of the earlier bis drafts. > > Second point is that 2543 already allows 1-of-N codec negotiation > through the use of a 3-way handshake (SDP in INVITE, subset in 200, > new SDP in ACK). So the statement that the 3-way handshake is not > backwards compatible is only with bis, not 2543, since the restriction > to offer/answer appears only in bis. I would argue that 2543 was simply unclear on this point entirely. It was never my impression that it allowed it, however, I can see how one my come to that conclusion (there is a sentence somewhere on updating the SDP in the ACK). SDP usage in rfc2543 was vastly underpsecified, overall. I would argue that most implementations today still only support SDP in INVITE/200, with nothing in the ACK. A few are beginning to support 200/ACK offer/answers. > Again this seems to be a > problem in bis, and should be fixed in bis. Offer/Counter-Offer/Answer > is a much cleaner solution than a two-stage invite (although as an > author > of the original two-stage invite proposal, > draft-dcsgroup-mmusic-resource-00, > June 1999, it is interesting that it has returned; all that is missing > is the No-Ring header in the first invite!). Bill, these snide remarks get us nowhere. As you are well aware, the issues with the two-stage invite in the original DCS had everything to do with the fact that the original INVITE was answered. Furthermore, even without answering the initial one, a two-stage INVITE is sufficiently complex, from a dialog-maintenance point of view, that we are not going to allow it. That is why it is INVITE followed by COMET instead. I would still like to know in what ways an three-way exchange is cleaner? It is a few messages shorter, for sure. However, it cannot do anything the two two-pass cannot do, either functionally, or in terms of latency. However, it adds complexity, since now we have two exchange mechanisms, and we will need to worry about how this interacts with 3pcc, how to signal which one is being used in which cases, and so on. The proposal eliminates all of that. As an example, with a three-pass exchange, the initial INVITE would need to indicate whether a counter-offer was expected, or just an answer. That requires a REquire header. Then, the UA will need to fall back to a regular offer/answer in the case it fails. The 200 OK, of course, would need an indicator somewhere about whether its an answer or counter-offer. If itsa counter-offer, we need to now specify procedures for error handling if the answer doesn't come in ACK, and so on. > > The early media, and handling of multiple early media streams, and > resource reservation before alerting, all seem to be more "extensions" > than "bugs", so I'd agree with them being in separate drafts. The line is fine indeed. I think a convincing argument could be made for it on either side. However, the argument is really philosophical in nature, and I am more concerned with practical issues right now. > But if > COMET (or UPDATE) is defined in bis, these drafts would be short. My main concern, and I am surprised its not yours as well, is timely completion of bis for 3gpp. To do that, we require parallelism. I would very much like to last call bis-06 as issued, and we could do that shortly if this stuff stays out. In parallel with the last call period, and iesg review, we can refine UPDATE/COMET, as this will take some time. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 10:04:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04439 for ; Fri, 25 Jan 2002 10:04:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA18761 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 10:04:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16026; Fri, 25 Jan 2002 09:10:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15898 for ; Fri, 25 Jan 2002 09:10:20 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03088; Fri, 25 Jan 2002 09:10:11 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0PEA2105633; Fri, 25 Jan 2002 15:10:02 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0PE9xr6017772; Fri, 25 Jan 2002 16:09:59 +0200 (EET) Message-ID: <3C516706.D66492FA@lmf.ericsson.se> Date: Fri, 25 Jan 2002 16:09:10 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Christian Huitema'" , Juha Heinanen , Dean Willis , sipping@ietf.org, "'Sip@ietf.org'" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] calling number blocking at sip/isup gateway Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, These are just some thoughts, so please don't flame me :) There was once a discussion (open issue #140) if the whole of the To- and From headers, or only the tag, should be used as call-leg/dialog identifiers. The decission was that they should. So, ASSUMING that ONLY the tags of the To- and From headers were used for the dialog identifier, I guess it wouldn't matter if proxy would modify the SIP-URI part of the To- and From headers? So, the question is: would that make the problem we are discussing here any easier? Also, after the session is established, the whole SIP-URI wouldn't have to be included in the SIP message To- and From headers in the first place, which could add some security, and which would make the messages at least a little shorter, but that's another issue... Again, I am NOT proposing anything, and I KNOW #140 is closed - I am just asking a simple question :) Regards, Christer Holmberg Ericsson Finland Mark Watson wrote: > > I have to say I am amazed too. But by the idea that the privacy > regulations we see in the PSTN/ISDN may not apply in the SIP world. > These stem from technology-neutral Data Protection legislation which > applies as much to SIP as to ISUP or TUP. > > Sure, in a model where there are no trust relationships, then if you > want to keep something private you either (a) don't send it at all (b) > encrypt so that only people you *do* trust can see it. > > It comes back to the trust model argument. > > I do think it likely though that there will be models where calls are > routed between service providers on the basis of Service Level > Agreements between those providers. If your SLA includes that the > other provider agrees to provide certain QoS etc. for your > subscriber's calls, it can also include provisions regarding trust of > user identities etc. > > There are also reasons why the Service Providers may wish to exchange > the identity/ies of the caller, but the caller may wish to remain > anonymous to the called party. > > Mayby these Service Providers are incredibly naive ? Mayby they should > be happy to rely on networks with which they have no SLA to deliver > calls on behalf of their subscribers ? Mayby there is no market for > better than best effort service ? > > Regards...Mark > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > Sent: 24 January 2002 18:01 > > To: Juha Heinanen; Dean Willis > > Cc: sipping@ietf.org > > Subject: RE: [Sipping] calling number blocking at sip/isup gateway > > > > > > > ok, i tried again and still can't figure out how my proxy > > can tell to > > a > > > trusted sip/isup gw that the calling user doesn't want his/her > phone > > > number to be shown to the called pstn user. i would like to be > able > > to > > > do something simple in the proxy, like adding a header > > > > > > Anonymity: from > > > > > > to the invite, but that kind of thing is not available. my > > suggestion > > > is that the authors of the privacy i-d and the sip-isup i-d > > figure it > > > out how to map isup Calling party indicator "Address presentation > > > restricted" to/from sip. before that is done, i would not > > vote going > > > forward with either i-d. > > > > There is an obvious tension between four issues: > > > > - The fact that when an UA is under the user's control, the content > of > > the header fields can be set to arbitrary values, and that any > header > > field can be expected to be read by the final user; > > - The legal requirement in many countries for "traceability", i.e. > the > > possibility for law enforcement to find the source of any phone > call; > > - The desire in many cases to place anonymous calls, i.e. without > > disclosing the identity and/or the location of the caller (Think > > "whistle blower"); > > - The desire in even more cases to block anonymous calls (Think > spam). > > > > The mix of the four makes for an unsavory soup. In the privacy > draft, > > the law enforcement requirement can only be met by letting a proxy > > insert a "Remote-Party-ID" header; but the moment you do that, you > > enable every party down the chain to see and display that header. To > > > prevent abuse, the draft creates a "RPID-Privacy" header that > > the caller > > should set to the appropriate value if it does not want the > > information > > casually displayed. > > > > Frankly, I am amazed by the naivety of the proposal. To make > > this work, > > you then need a "chain of trust" between all the proxies; yet, we > have > > no mechanism to determine this level of trust. We also need to > assume > > that the information will not be displayed by the called UA > regardless > > of the value in the privacy field, which goes contrary to what we > see > > with e-mail, and also goes contrary to the obvious desire to > > fight spam. > > > > Frankly, I don't find this privacy draft useful or adequate. > > It attempts > > to comply with telephony-era regulations that have basically > > no meaning > > in the Internet. In fact, we could probably meet these regulations > by > > having a much simpler solution that directly target ISUP > > compatibility: > > a calling telephone number header, with a privacy tag, that > > gateways to > > the telephone network could directly translate. > > > > -- Christian Huitema > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 10:10:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04647 for ; Fri, 25 Jan 2002 10:10:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA19118 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 10:10:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16537; Fri, 25 Jan 2002 09:25:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16470 for ; Fri, 25 Jan 2002 09:25:21 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03417; Fri, 25 Jan 2002 09:25:16 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15315; Fri, 25 Jan 2002 09:24:44 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29146; Fri, 25 Jan 2002 09:24:46 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Jan 2002 09:24:45 -0500 Message-ID: <313680C9A886D511A06000204840E1CF01D80672@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: infovaan@lycos.com, SIP Implementors Group , SIP List , SIP , SIP-NG Date: Fri, 25 Jan 2002 09:24:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] RE: [Sipping] how do we handle 911 call originated by SIP user? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org NEVER, EVER send the same message to two lists. Most of the people who would respond are on all the lists. Choose one; if you choose the wrong one, someone will move it. Brian > -----Original Message----- > From: Info Van [mailto:infovaan@lycos.com] > Sent: Friday, January 18, 2002 10:10 AM > To: SIP Implementors Group; SIP List; SIP; SIP-NG > Subject: [Sipping] how do we handle 911 call originated by SIP user? > > > hi, > > for SIP->PSTN call, is there any ID or any other work-in-progress, > any suggestion, as to how do we handle SIP->911 calls ?? the problem > as i see it :- > 1) SIP user can log on from any domain (and be a dial-up user > who get's a new IP everytime) > 2) SIP UA currently doesn't seem to have any MANDATORY > "geographic-location" (not necessarily GPS based, but say > "postal address based") location information that can be > relayed onto the PSAP. > 3) SIP user could be a mobile-IP user where finding out > location and IP bindings i believe is very costly!! (not sure > on that). > > how do we plan to handle this ? i know this is a problem > we've lived with in 2-2.5G Mobile networks (and found some > solutions too), but i don't see any "triangulation" out > here... obviously implementors, network operators would be > mandated by FCC regs. to provide 911... so... how does the > SIP-ASP (service provider) make sure that the UA's like > Pingtel, HearMe or any other co. provide location info, > without standardizing it...?? > > i'm sure this has been discussed (but not sure if it's been > solved and taken care of) already... sorry for cross-posting, > but i thought it right because i wasn't sure if this is a > future-work, work-in-progress, or under-implementation (could > be all the 3). > > thanks for any/all inputs, > bdutta. > > > > > _______________________________________________ > 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 > This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachment, use the contents for any purposes, or disclose the contents to any other person: to do so could be a breach of confidence. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 11:13:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06243 for ; Fri, 25 Jan 2002 11:13:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23408 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 11:13:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21395; Fri, 25 Jan 2002 10:49:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21366 for ; Fri, 25 Jan 2002 10:49:19 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05516 for ; Fri, 25 Jan 2002 10:49:15 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Fri Jan 25 10:42:26 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0PFlfL10327; Fri, 25 Jan 2002 10:47:41 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA12110; Fri, 25 Jan 2002 10:47:40 -0500 (EST) Message-ID: <3C517D30.EF110940@cs.columbia.edu> Date: Fri, 25 Jan 2002 10:43:44 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C50D5D4.8F5A642C@cs.columbia.edu> <3C50F223.26B1FF68@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Henning Schulzrinne wrote: > > > > I agree, except that "support" may simply mean to return 606 or 486. > > That won't help, unless we mandate that clients retry with a SIP URL. There are only two choices that I can see: 1) The proxy at hotel.com translates tel:7 into sip:something@hotel.com and then routes it. 2) The proxy knows that it can't handle telephone numbers, and has to do something. One alternative is to say that the proxy should do a mechanical translation into sip:@localdomain and then normal behavior (404) kicks in if this is not a valid entry. The other is to return an error and it would be up to the user or UA implementation to try the sip variant. > > > There is no obligation for every proxy to have a PSTN gateway. > > It has nothing to do with PSTN; consider Dean's "7 for housekeeping > scenario", where the UA inserts tel:7. I suppose if the hotel has SIP phones and says "dial 7", it has the necessary plumbing in place to make this happen. If the number is printed on the bedside phone, but Dean dials it from the SIP phone he carries in his pocket, the rules above might rationalize the behavior. From a guest phone, some amount of surprise is unavoidable - after all, dialing 7 on my mobile phone when in the hotel doesn't get me housekeeping, either. > > > The user > > can then specify a suitable sip:@domain to place the call. > > The user, or the UA? This seems a burden for the user. I think they will > view it as a system failure if they type something into their SIP phone > and it never works, because their proxy doesn't support tel URL. That's why we need either automatic translation (which is easy enough to support so that there's no excuse) or an explicit error code. > > > I don't know > > if we need an explicit status code or Warning code for this case. I > > think a status code (URI scheme not supported) would be useful to make > > this case explicit. This may turn out to be useful for other things, > > such as IMPP. > > Sounds here like you are proposing that the UA retry with a SIP URL this > time. Is it better for the proxy to support tel URL, so it succeeds the > first time, or for the UA to have to try tel, fail, then try SIP, and > have to figure out what domain to put in the SIP URL? As long as it is clear that this can indeed do something useful. What does "support" a tel URL mean? Forward the (non-housekeeping) call to a carrier? > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Fri Jan 25 12:02:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07537 for ; Fri, 25 Jan 2002 12:02:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27701 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 12:02:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25590; Fri, 25 Jan 2002 11:41:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25529 for ; Fri, 25 Jan 2002 11:41:09 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06861; Fri, 25 Jan 2002 11:41:03 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id QAA23950; Fri, 25 Jan 2002 16:38:53 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id QAA04601; Fri, 25 Jan 2002 16:41:01 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 09:41:01 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B37189@n0214idc1.oss.level3.com> To: christer.holmberg@lmf.ericsson.se Cc: huitema@windows.microsoft.com, jh@lohi.eng.song.fi, dean.willis@softarmor.com, sipping@ietf.org, mwatson@nortelnetworks.com, Sip@ietf.org Date: Fri, 25 Jan 2002 09:41:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [Sipping] calling number blocking at sip/isup gateway Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > Hi, > > These are just some thoughts, so please don't flame me :) > > There was once a discussion (open issue #140) if the whole of the To- > and From headers, or only the tag, should be used as call-leg/dialog > identifiers. > > The decission was that they should. > > So, ASSUMING that ONLY the tags of the To- and From headers were used > for the dialog identifier, I guess it wouldn't matter if proxy would > modify the SIP-URI part of the To- and From headers? So, the question > is: would that make the problem we are discussing here any easier? Sounds dangerous for backward compatibility, as most UAs out there still use these headers to ID the session. > > Also, after the session is established, the whole SIP-URI > wouldn't have > to be included in the SIP message To- and From headers in the first > place, which could add some security, and which would make > the messages > at least a little shorter, but that's another issue... > > Again, I am NOT proposing anything, and I KNOW #140 is closed - I am > just asking a simple question :) > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > Mark Watson wrote: > > > > I have to say I am amazed too. But by the idea that the privacy > > regulations we see in the PSTN/ISDN may not apply in the SIP world. > > These stem from technology-neutral Data Protection legislation which > > applies as much to SIP as to ISUP or TUP. > > > > Sure, in a model where there are no trust relationships, then if you > > want to keep something private you either (a) don't send it > at all (b) > > encrypt so that only people you *do* trust can see it. > > > > It comes back to the trust model argument. > > > > I do think it likely though that there will be models where > calls are > > routed between service providers on the basis of Service Level > > Agreements between those providers. If your SLA includes that the > > other provider agrees to provide certain QoS etc. for your > > subscriber's calls, it can also include provisions > regarding trust of > > user identities etc. > > > > There are also reasons why the Service Providers may wish > to exchange > > the identity/ies of the caller, but the caller may wish to remain > > anonymous to the called party. > > > > Mayby these Service Providers are incredibly naive ? Mayby > they should > > be happy to rely on networks with which they have no SLA to deliver > > calls on behalf of their subscribers ? Mayby there is no market for > > better than best effort service ? > > > > Regards...Mark > > > > > -----Original Message----- > > > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > > > Sent: 24 January 2002 18:01 > > > To: Juha Heinanen; Dean Willis > > > Cc: sipping@ietf.org > > > Subject: RE: [Sipping] calling number blocking at sip/isup gateway > > > > > > > > > > ok, i tried again and still can't figure out how my proxy > > > can tell to > > > a > > > > trusted sip/isup gw that the calling user doesn't want his/her > > phone > > > > number to be shown to the called pstn user. i would like to be > > able > > > to > > > > do something simple in the proxy, like adding a header > > > > > > > > Anonymity: from > > > > > > > > to the invite, but that kind of thing is not available. my > > > suggestion > > > > is that the authors of the privacy i-d and the sip-isup i-d > > > figure it > > > > out how to map isup Calling party indicator "Address > presentation > > > > restricted" to/from sip. before that is done, i would not > > > vote going > > > > forward with either i-d. > > > > > > There is an obvious tension between four issues: > > > > > > - The fact that when an UA is under the user's control, > the content > > of > > > the header fields can be set to arbitrary values, and that any > > header > > > field can be expected to be read by the final user; > > > - The legal requirement in many countries for "traceability", i.e. > > the > > > possibility for law enforcement to find the source of any phone > > call; > > > - The desire in many cases to place anonymous calls, i.e. without > > > disclosing the identity and/or the location of the caller (Think > > > "whistle blower"); > > > - The desire in even more cases to block anonymous calls (Think > > spam). > > > > > > The mix of the four makes for an unsavory soup. In the privacy > > draft, > > > the law enforcement requirement can only be met by letting a proxy > > > insert a "Remote-Party-ID" header; but the moment you do that, you > > > enable every party down the chain to see and display that > header. To > > > > > prevent abuse, the draft creates a "RPID-Privacy" header that > > > the caller > > > should set to the appropriate value if it does not want the > > > information > > > casually displayed. > > > > > > Frankly, I am amazed by the naivety of the proposal. To make > > > this work, > > > you then need a "chain of trust" between all the proxies; yet, we > > have > > > no mechanism to determine this level of trust. We also need to > > assume > > > that the information will not be displayed by the called UA > > regardless > > > of the value in the privacy field, which goes contrary to what we > > see > > > with e-mail, and also goes contrary to the obvious desire to > > > fight spam. > > > > > > Frankly, I don't find this privacy draft useful or adequate. > > > It attempts > > > to comply with telephony-era regulations that have basically > > > no meaning > > > in the Internet. In fact, we could probably meet these regulations > > by > > > having a much simpler solution that directly target ISUP > > > compatibility: > > > a calling telephone number header, with a privacy tag, that > > > gateways to > > > the telephone network could directly translate. > > > > > > -- Christian Huitema > > > > > > _______________________________________________ > > > 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 > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 25 14:15:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11509 for ; Fri, 25 Jan 2002 14:15:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA03977 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 14:15:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02353; Fri, 25 Jan 2002 13:41:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02311 for ; Fri, 25 Jan 2002 13:41:45 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10622 for ; Fri, 25 Jan 2002 13:41:37 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-32 #42257) id <0GQI00B01BW361@firewall.wcom.com> for sip@ietf.org; Fri, 25 Jan 2002 18:40:51 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GQI00B0VBW22T@firewall.wcom.com>; Fri, 25 Jan 2002 18:40:51 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQI00401BVQPB@pmismtp04.wcomnet.com>; Fri, 25 Jan 2002 18:40:50 +0000 (GMT) Received: from ajohnston ([166.42.33.203]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GQI0040KBVNO0@pmismtp04.wcomnet.com>; Fri, 25 Jan 2002 18:40:37 +0000 (GMT) Date: Fri, 25 Jan 2002 12:40:08 -0600 From: Alan Johnston Subject: RE: [Sip] Re: Unify draft and 1-of-N In-reply-to: <200201251333.IAA87743@fish.research.att.com> To: "'William Marshall'" , sip@ietf.org Message-id: <001601c1a5cf$b71ba4a0$cb212aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bill, See my comments below. Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of William Marshall > Sent: Friday, January 25, 2002 7:33 AM > To: sip@ietf.org > Subject: Re: [Sip] Re: Unify draft and 1-of-N > > > I'm very concerned about the call flow shown in section 5.1 > of the unify draft, which does codec negotiation through the > use of a Re-INVITE. > > The main problem is the resulting post-pickup delay. When > more than a few hundred milliseconds, it results in a failed > call (from the user's view) and a completed billable call > (from the provider's view). Not a happy situation, > especially if it occurs on every call attempt. Retraining > the users is hardly an option. No - this is not a problem. If I send an INVITE listing three codecs then I must be prepared to receive media from any of those codecs. Once the first media packet arrives, I load that codec and the call proceeds. The 1-of-N is problem is that at some later date, the far end may switch to one of the other two codecs that I do not currently have loaded. As a result, before this switch occurs, I need to re-INVITE to settle in on the codec which is currently in use. As a result, the re-INVITE has no effect on the media stream - no dropped packets, interruptions, or post dial delay. > > The only way I see to resolve this is to delay the ringing > until the re-INVITE, when the codec set is known and the > extra roundtrips are not needed before the media path is > established. And this leads to all the problems with the > original two-stage invite. These are non problems unless the far end system does something crazy like randomly switching between the set of codecs. > > The much better solution is shown in the unify draft in > section 5.5, figure 12, utilizing a COMET/UPDATE (message > (5)) that picks the codec to use. > > I would really hate to see the re-INVITE of section 5.1 described > in bis-06 because of not wanting to define the COMET/UPDATE > method. Much better to state that codec negotiation is not > suspported in bis, and requires an extension, and then not > have to consider the backwards compatibility problems with > UA's that do the immediate re-INVITE. > The re-INVITE call flow is perfectly legitimate in bis as well as RFC 2543 for that matter and any SIP system must be able to handle it. If your system does not support a re-INVITE it is a seriously broken UA. > Bill Marshall > wtm@research.att.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 25 14:16:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11551 for ; Fri, 25 Jan 2002 14:16:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA04076 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 14:16:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02717; Fri, 25 Jan 2002 13:50:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02686 for ; Fri, 25 Jan 2002 13:50:41 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10804 for ; Fri, 25 Jan 2002 13:50:38 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GQI00M01CAJNT@firewall.wcom.com> for sip@ietf.org; Fri, 25 Jan 2002 18:49:31 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GQI00LAVCAIAB@firewall.wcom.com>; Fri, 25 Jan 2002 18:49:31 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQI00901C9C4Z@pmismtp04.wcomnet.com>; Fri, 25 Jan 2002 18:49:30 +0000 (GMT) Received: from ajohnston ([166.42.33.203]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GQI004MTC96OZ@pmismtp04.wcomnet.com>; Fri, 25 Jan 2002 18:48:44 +0000 (GMT) Date: Fri, 25 Jan 2002 12:48:15 -0600 From: Alan Johnston Subject: RE: [Sip] Comments on "unify" draft In-reply-to: <200201222059.PAA44216@fish.research.att.com> To: "'William Marshall'" , sip@ietf.org Message-id: <001701c1a5d0$d9543680$cb212aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Bill, See my comments below. Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of William Marshall > Sent: Tuesday, January 22, 2002 2:59 PM > To: sip@ietf.org > Subject: Re: [Sip] Comments on "unify" draft > > > Jonathan wrote: > > > > In general, it would be helpful to get general feedback of the form > > "seems like the right direction". Particularly, the main > thing I need > > feedback on ASAP is the proposal to pretty much keep this > all out of > > bis. The only thing in bis would be some generalized > statement of when > > you can see offers and answers, so that we can separate the > > EM/manyfolks/herfp solutions from bis. Granted, this stuff > still needs > > to be on the fast track for 3g, but I want to get it > separated from bis. > > > > First, I definitely agree this aspect should be decided quickly. > > I may be in the minority, but I think that a problem in 2543 should > be fixed in the next version of the RFC, and that HERFP qualifies > as a bug in 2543. It seems wrong to have a "supported:" tag defined > for a fix for a bug. > > The main argument against this that I see is one of backwards > compatability. But everyone seems to agree that a UA or proxy > written to conform to 2543 is nearly useless - so the question > seems to be one of backwards compatability to what? Do we really > need to maintain backwards comatability to a I-D, defined as only > a "Work in Progress"? With the definition of Route and Record-Route > in bis, we've already given up backwards compatability with a > pure-2543 proxy, and a fix for HERFP does not make the situation > any worse. > Some of us do have commercial SIP products and they do work with RFC 2543 devices. This is also probably true for most of the SIP service providers listed on Henning's page. HERFP is a nice thing for a fix, but it is should not be classified as a bug. > Second point is that 2543 already allows 1-of-N codec negotiation > through the use of a 3-way handshake (SDP in INVITE, subset in 200, > new SDP in ACK). So the statement that the 3-way handshake is not > backwards compatible is only with bis, not 2543, since the > restriction > to offer/answer appears only in bis. This is not correct - there have never been any working group documents on base SIP (not extension) that show this incorrect behavior. Interworkable SIP is shown in the call flows and by testing at SIPit. This three way handshake is wrong. Again this seems to be a > problem in bis, and should be fixed in bis. > Offer/Counter-Offer/Answer > is a much cleaner solution than a two-stage invite (although > as an author > of the original two-stage invite proposal, > draft-dcsgroup-mmusic-resource-00, > June 1999, it is interesting that it has returned; all that is missing > is the No-Ring header in the first invite!). > > The early media, and handling of multiple early media streams, and > resource reservation before alerting, all seem to be more "extensions" > than "bugs", so I'd agree with them being in separate drafts. But if > COMET (or UPDATE) is defined in bis, these drafts would be short. > By the way, I support the direction of the unify draft, although I need to think more call flows before I come to a conclusion. It is definitely better than the present COMET method as outlined in manyfolks. > Bill Marshall > wtm@research.att.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 25 14:31:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12069 for ; Fri, 25 Jan 2002 14:31:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA05046 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 14:31:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02891; Fri, 25 Jan 2002 13:54:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02860 for ; Fri, 25 Jan 2002 13:54:49 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10959 for ; Fri, 25 Jan 2002 13:54:46 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 331D14CEA1 for ; Fri, 25 Jan 2002 13:54:46 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA15912; Fri, 25 Jan 2002 13:54:43 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id NAA93476; Fri, 25 Jan 2002 13:56:07 -0500 (EST) Date: Fri, 25 Jan 2002 13:56:07 -0500 (EST) Message-Id: <200201251856.NAA93476@fish.research.att.com> To: sip@ietf.org Subject: RE: [Sip] Re: Unify draft and 1-of-N Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Alan Johnston wrote: > Bill Marshall wrote: > > I'm very concerned about the call flow shown in section 5.1 > > of the unify draft, which does codec negotiation through the > > use of a Re-INVITE. > > > > The main problem is the resulting post-pickup delay. When > > more than a few hundred milliseconds, it results in a failed > > call (from the user's view) and a completed billable call > > (from the provider's view). Not a happy situation, > > especially if it occurs on every call attempt. Retraining > > the users is hardly an option. > > No - this is not a problem. If I send an INVITE listing three codecs > then I must be prepared to receive media from any of those codecs. Once > the first media packet arrives, I load that codec and the call proceeds. But the problem is that 5.1 sent an INVITE listing all as a=inactive, so the UAC is not preparing to receive any media at all. It is not until the second INVITE (after the called party has answered) that any receive ports are assigned. This is what causes the extreme post-pickup delay. While I recognize that this call flow is perfectly legitimate in 2543 as well as bis, it has certain problems and should not be considered as solving anything. Bill Marshall wtm@research.att.com -----original message----- Date: Fri, 25 Jan 2002 12:40:08 -0600 From: Alan Johnston Subject: RE: [Sip] Re: Unify draft and 1-of-N To: "'William Marshall'" , sip@ietf.org Bill, See my comments below. Alan Johnston WorldCom sip:alan@siptest.wcom.com > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On > Behalf Of William Marshall > Sent: Friday, January 25, 2002 7:33 AM > To: sip@ietf.org > Subject: Re: [Sip] Re: Unify draft and 1-of-N > > > I'm very concerned about the call flow shown in section 5.1 > of the unify draft, which does codec negotiation through the > use of a Re-INVITE. > > The main problem is the resulting post-pickup delay. When > more than a few hundred milliseconds, it results in a failed > call (from the user's view) and a completed billable call > (from the provider's view). Not a happy situation, > especially if it occurs on every call attempt. Retraining > the users is hardly an option. No - this is not a problem. If I send an INVITE listing three codecs then I must be prepared to receive media from any of those codecs. Once the first media packet arrives, I load that codec and the call proceeds. The 1-of-N is problem is that at some later date, the far end may switch to one of the other two codecs that I do not currently have loaded. As a result, before this switch occurs, I need to re-INVITE to settle in on the codec which is currently in use. As a result, the re-INVITE has no effect on the media stream - no dropped packets, interruptions, or post dial delay. > > The only way I see to resolve this is to delay the ringing > until the re-INVITE, when the codec set is known and the > extra roundtrips are not needed before the media path is > established. And this leads to all the problems with the > original two-stage invite. These are non problems unless the far end system does something crazy like randomly switching between the set of codecs. > > The much better solution is shown in the unify draft in > section 5.5, figure 12, utilizing a COMET/UPDATE (message > (5)) that picks the codec to use. > > I would really hate to see the re-INVITE of section 5.1 described > in bis-06 because of not wanting to define the COMET/UPDATE > method. Much better to state that codec negotiation is not > suspported in bis, and requires an extension, and then not > have to consider the backwards compatibility problems with > UA's that do the immediate re-INVITE. > The re-INVITE call flow is perfectly legitimate in bis as well as RFC 2543 for that matter and any SIP system must be able to handle it. If your system does not support a re-INVITE it is a seriously broken UA. > Bill Marshall > wtm@research.att.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 25 15:25:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13276 for ; Fri, 25 Jan 2002 15:25:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07784 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 15:25:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06861; Fri, 25 Jan 2002 15:04:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06831 for ; Fri, 25 Jan 2002 15:04:39 -0500 (EST) Received: from mail1.telefonica.com.ar ([168.226.49.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12821 for ; Fri, 25 Jan 2002 15:04:34 -0500 (EST) Received: by MAIL1 with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 17:03:49 -0300 Message-ID: <19364262E259D51198BA0008C7E6528E091B82@MSTELEFONICA8> From: De Leo Walter To: "'Jonathan Rosenberg'" Cc: "'sip@ietf.org'" Date: Fri, 25 Jan 2002 16:51:28 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] draft-rosenberg-sip-app-components-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org As this draft has expired I'd like to know if there is a new version in the oven or it has been renamed or let die. Regards. Walter _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Fri Jan 25 15:25:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13292 for ; Fri, 25 Jan 2002 15:25:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA07798 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 15:25:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06927; Fri, 25 Jan 2002 15:05:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA06893 for ; Fri, 25 Jan 2002 15:05:46 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12834 for ; Fri, 25 Jan 2002 15:05:41 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g0PK4UN01830; Fri, 25 Jan 2002 14:04:30 -0600 Message-Id: <200201252004.g0PK4UN01830@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: Jonathan Rosenberg , Henning Schulzrinne Subject: Re: [Sip] Open Issue #366: sip v. tel URL Date: Fri, 25 Jan 2002 14:04:27 -0600 X-Mailer: KMail [version 1.3.2] Cc: sip@ietf.org References: <3C50D5D4.8F5A642C@cs.columbia.edu> <3C50F223.26B1FF68@dynamicsoft.com> In-Reply-To: <3C50F223.26B1FF68@dynamicsoft.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Thursday 24 January 2002 11:50 pm, Jonathan Rosenberg wrote: > The user, or the UA? This seems a burden for the user. I think they > will view it as a system failure if they type something into their > SIP phone and it never works, because their proxy doesn't support tel > URL. no different than dialing direct for a calling-credit-card call, getting a reorder tone, and trying the 800-number access mode for the calling card service as an alternative. Happens to me weekly in random hotels. Ofcourse, if the hotel has a sign that says "Dial tel:7 for room service", I expect the local proxy will understand tel: URLs. > > I don't know > > if we need an explicit status code or Warning code for this case. I > > think a status code (URI scheme not supported) would be useful to > > make this case explicit. This may turn out to be useful for other > > things, such as IMPP. > > Sounds here like you are proposing that the UA retry with a SIP URL > this time. Is it better for the proxy to support tel URL, so it > succeeds the first time, or for the UA to have to try tel, fail, then > try SIP, and have to figure out what domain to put in the SIP URL? An explicit code would make the user experience better than is currently supported for access-mode errors on 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 daemon@ns.ietf.org Fri Jan 25 19:50:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19056 for ; Fri, 25 Jan 2002 19:50:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA20312 for sip-archive@odin.ietf.org; Fri, 25 Jan 2002 19:50:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19534; Fri, 25 Jan 2002 19:22:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19472 for ; Fri, 25 Jan 2002 19:22:30 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18783; Fri, 25 Jan 2002 19:22:26 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0Q0KM8n017868; Sat, 26 Jan 2002 01:20:22 +0100 (MET) Received: from lmf.ericsson.se (lmf05397pc.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0Q0KLr6012840; Sat, 26 Jan 2002 02:20:21 +0200 (EET) Message-ID: <3C51F646.1AB8DDE0@lmf.ericsson.se> Date: Sat, 26 Jan 2002 02:20:22 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: John.Hearty@Level3.com CC: huitema@windows.microsoft.com, jh@lohi.eng.song.fi, dean.willis@softarmor.com, sipping@ietf.org, mwatson@nortelnetworks.com, Sip@ietf.org References: <17052388D394D411803900508BDFFAF601B37189@n0214idc1.oss.level3.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [Sipping] calling number blocking at sip/isup gateway Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>These are just some thoughts, so please don't flame me :) >> >>There was once a discussion (open issue #140) if the whole of the To- >>and From headers, or only the tag, should be used as call-leg/dialog >>identifiers. >> >>The decission was that they should. >> >>So, ASSUMING that ONLY the tags of the To- and From headers were used >>for the dialog identifier, I guess it wouldn't matter if proxy would >>modify the SIP-URI part of the To- and From headers? So, the question >>is: would that make the problem we are discussing here any easier? > >Sounds dangerous for backward compatibility, as most UAs out there still >use these headers to ID the session. Well, the UAS would always see the same header values. And, if the proxy which changes the headers also inserts itself in the route, it could always by default change the headers back when sending a message (request or reply) to the UAC, so the header values between the UAC and that proxy would also always be the same. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jan 26 04:54:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04568 for ; Sat, 26 Jan 2002 04:54:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA15489 for sip-archive@odin.ietf.org; Sat, 26 Jan 2002 04:54:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14594; Sat, 26 Jan 2002 04:21:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14553 for ; Sat, 26 Jan 2002 04:21:36 -0500 (EST) Received: from www16-cn.sinonets.net.cn ([202.99.11.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04308 for ; Sat, 26 Jan 2002 04:21:31 -0500 (EST) From: info@polyglot.com.cn Received: from An [218.19.24.52] by www16-cn.sinonets.net.cn (SMTPD32-6.06) id A49F9BC012E; Sat, 26 Jan 2002 17:19:27 +0800 Date: ÐÇÆÚÁù, 26 Ò»Ô 2002 17:21:46 +0800 Content-Type: text/plain To: sip@ietf.org X-Library: WinShoes 7.035B X-Mailer: MSEND 1.01A Message-Id: <20020126171946.SM01104@An> Subject: [Sip] Polyglot Translation רҵ·­Òë Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Polyglot Translation Co., Ltd. We are a professional translation organization that provides translation, interpretation, and simultaneous meeting interpretation in all fields. In addition, we provide localization of websites into Chinese, writing articles in multi-languages, foreign languages recording, proofreading, Interpreters/translators recommending, website designing and making and so on. We can provide a large variety of languages translating services such as English, Japanese, French, German, Russian, Korean, Italian, Spanish, Dutch, Swedish, Finnish, Portuguese, Czechish, Slovak,Romanian, Polish, Hungarian,Bulgarian,Arabic,Turkish,Cambodian, Malay, Indonesian, Thai, Vietnamese, Nepali, Laotian, Burmese, Mongolian, Indic, Bengalese, Tamil and so on. Altogether, we can provide more than 30 languages translation service fast and accurately. For the details, please visit our website: http://www.polyglot.com.cn http://www.chinapolyglot.com Contact us: E-mail: info@polyglot.com.cn Tel: +86-20-86573608 Fax: +86-20-86573965 Add: Rm. 968 Office Tower Central Hotel 33 Airport Road, Guangzhou, China The message below is written in Chinese characters: ±£Á¢ÐÅ·­Ò빫˾ ±£Á¢ÐÅ·­Ò빫˾ÊÇÒ»¼Òרҵ·­Òë»ú¹¹,¿ÉÌṩ¸÷¸öÁìÓòµÄ±ÊÒë¡¢¿ÚÒë¡¢»áÒé µÄͬÉù´«Òë¡£ ´ËÍ⣬Ϊ¸÷ÀàÖÐÍâÍøÕ¾Ìṩ·­Òë°æ±¾£¬ÒÔ¼°Îª¿Í»§Ìṩ¶àÖÖÓïÑÔµÄ׫¸å·þÎñ¡¢ ÍâÎļÒô¡¢Ð£¸å¡¢·­ÒëÍƼö¡¢ÍøÕ¾Éè¼Æ¡¢ÖÆ×÷µÈ¡£ ·­ÒëÓïÖÖ£º¿ÉÌṩӢ¡¢ÈÕ¡¢·¨¡¢µÂ¡¢¶í¡¢º«¡¢Òâ´óÀû¡¢Î÷°àÑÀ¡¢ºÉÀ¼¡¢Èðµä¡¢ ·ÒÀ¼¡¢ÆÏÌÑÑÀ¡¢½Ý¿Ë¡¢Ë¹Âå·¥¿Ë¡¢ÂÞÂíÄáÑÇ¡¢²¨À¼¡¢ÐÙÑÀÀû¡¢±£¼ÓÀûÑÇ¡¢°¢À­²®¡¢ ÍÁ¶úÆä¡¢¼íÆÒÕ¯¡¢ ÂíÀ´¡¢Ó¡Äᡢ̩¡¢Ô½ÄÏ¡¢Äá²´¶û¡¢ ÀÏÎΡ¢Ãåµé¡¢Ãɹš¢Ó¡¶È¡¢ ÃϼÓÀ­¡¢Ì©Ã׶ûµÈÈýÊ®¶àÃÅÍâÓï×î׼ȷ¡¢¿ì½ÝµÄ·­ÒëµÄ·þÎñ¡£ ¹ØÓÚÏêÇ飬Çë²Î¹ÛÎÒÃǵÄÍøÖ·£º http://www.polyglot.com.cn http://www.chinapolyglot.com ÁªÏµ·½Ê½£º µçÓÊ: info@polyglot.com.cn µç»°: 020-86573608 ´«Õæ: 020-86573965 µØÖ·£ºÖйú¹ãÖÝ»ú³¡Â·33ºÅÖÐÑë¾Æµêд×ÖÂ¥968 Óʱࣺ510403 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sat Jan 26 21:02:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13245 for ; Sat, 26 Jan 2002 21:02:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14368 for sip-archive@odin.ietf.org; Sat, 26 Jan 2002 21:02:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13083; Sat, 26 Jan 2002 20:28:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13052 for ; Sat, 26 Jan 2002 20:28:50 -0500 (EST) Received: from localhost ([211.117.232.146]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12862 for ; Sat, 26 Jan 2002 20:28:41 -0500 (EST) Message-Id: <200201270128.UAA12862@ietf.org> Reply-To: office7000@yahoo.co.kr From: â¾÷Á¤º¸ To: sip@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sun, 27 Jan 2002 10:28:56 +0900 Subject: [Sip] [±¤°í] µ· µÇ´Â »ç¾÷Á¤º¸ÀÔ´Ï´Ù Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org ±ÍÇÏÀÇ Ã¢¾÷À» µ½°Ú½À´Ï´Ù.

 

 ±ÍÇÏÀÇ Ã¢¾÷À» µ½°Ú½À´Ï´Ù.  

 ÀúÈñ (ÁÖ)³ª·¡Á¤º¸¿¡¼­´Â ÀüÈ­Á¤º¸ â¾÷ÀÚ¸¦ ¸ð½Ê´Ï´Ù.

 º»  »ç¾÷¼Ò¿¡¼­ º¸À¯ÇÑ ¾ÆÀÌÅÛÀ» µå¸±¼öµµ ÀÖ½À´Ï´Ù.

±ÍÇϲ²¼­ °èȹÇϽŠ¾ÆÀÌÅÛÀ» ¼öÀͼº ÀÖ´Â »ç¾÷À¸·Î ¸¸µé¾î µå¸®°Ú½À´Ï´Ù.

¼ö³â°£ÀÇ ±â¼ú°ú ³ëÇÏ¿ì·Î ÃÖ¼±À» ´ÙÇϸç, °í°´ÀÇ ÀÌÀÍ°ú »ç¾÷ÀÇ ¹ßÀüÀ» À§ÇØ ³ë·ÂÇÏ´Â ±â¾÷À¸·Î

±ÍÇÏÀÇ °ç¿¡ ³¡±îÁö ³²°Ú½À´Ï´Ù.

ÀüÈ­Á¤º¸(700, 060, 800, 0600)Ư¡

  1. Ưº°ÇÑ ÀÚ°ÝÀ» ¿äÇÏÁö ¾Ê½À´Ï´Ù.(»ç¾÷ÀÚ µî·ÏÁõ ÇÊ¿ä)

  2. ¼ö±ÝÀÇ Çʿ伺ÀÌ ¾ø½À´Ï´Ù.(°¢ Åë½Å»ç ¼ö±Ý´ëÇà)

  3. Ÿ »ç¾÷º¸´Ù ¿î¿µ°ú °ü¸®°¡ Æí¸®ÇÕ´Ï´Ù.(ÀüÈ­·Î °ü¸®°¡´É)

  4. ±ÍÇϸ¸ÀÇ ³ëÇÏ¿ì·Î Á¤º¸¸¦ Á¦°øÇÕ´Ï´Ù.(¾ÆÀÌÅÛÁ¦°ø)

  5. »ç¾÷¼º Ÿ´ç¿©ºÎ Á¶»ç.(½ÃÀ强 Á¶»ç ´ëÇà)

  6. â¾÷ÀÚ±ÝÁö¿ø.(â¾÷ÀÚ±ÝÀÇ 50%Áö¿ø, ¼öÀÍ±Ý Ã¢ÃâÈÄ¿¡ ¼ö±Ý)

  7. »ç¾÷ÀÇ Áö¼Ó¼º.(½Ã½ºÅÛ º»»ç °ü¸®. »ç¾÷ÀÚ´Â ±âȹ°ú ±¤°í)

  8. »ç¾÷ÀÇ ¾ÈÀü¼º.(Çѱ¹Åë½Å, Çϳª·ÎÅë½Å, µ¥ÀÌÄÞµî°ú ¿¬°èÇÏ¿© »ç¾÷¿µÀ§)

  9. º»»çÀÇ Áö¿ø.((ÁÖ)³ª·¡¿¡¼­ »ç¾÷ÀÚµî·Ï½Åû, ½Ã½ºÅÛÁ¦ÀÛ, ¿î¿µ, °ü¸®)

 10. ÀåºñÀÓ´ë.(±Ý3,100,000¿øÀ¸·Î ÀåºñÀÏü¿Í ÇÁ·Î±×·¥À» Á¦°øÇÕ´Ï´Ù.)

 

"±¤°í¸ÞÀÏ´ëÇà"  ¸µÅ©ÇØÁÖ¼¼¿ä  

°¡Àå ºü¸¥ ±¤°íÈ¿°úÀÔ´Ï´Ù. ºü¸¥ ½Ã°£¾È¿¡ È®½ÇÇÑ È¿°ú¸¦ º¸½Ç¼ö ÀÖ½À´Ï´Ù. À̺¸´Ù  ¶Ù¾î³­ ±¤°íÈ¿°ú¸¦ ±â´ëÇÒ ¼ö ¾ø½À´Ï´Ù. ÀúÈñ ȸ¿ø¿¡ ÇÑÇÏ¿© ÈĺҷΠ°áÀç ¹Þ½À´Ï´Ù.
 
                    

 ±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥¼­ÇÎÁß, http://www.xxxxxxxx.com/
¿¡¼­ ¾Ë°Ô µÈ°ÍÀ̸ç, E-Mail ÁÖ¼Ò ¿Ü¿¡, ´Ù¸¥ Á¤º¸´Â °®°í ÀÖÁö ¾Ê½À´Ï´Ù.
Á¤ÅëºÎ ±Ç°í»çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó°í Ç¥±âÇÑ ¸ÞÀÏÀÔ´Ï´Ù. ¿øÄ¡ ¾ÊÀ¸¸é ,¼ö½Å°ÅºÎ¸¦ ´­·¯ÁÖ¼¼¿ä

           

 

_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 27 13:50:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02148 for ; Sun, 27 Jan 2002 13:50:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21313 for sip-archive@odin.ietf.org; Sun, 27 Jan 2002 13:50:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20489; Sun, 27 Jan 2002 13:29:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20458 for ; Sun, 27 Jan 2002 13:29:22 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02009 for ; Sun, 27 Jan 2002 13:29:20 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0RITO6Y001846; Sun, 27 Jan 2002 13:29:26 -0500 (EST) Message-ID: <3C5446DE.B5370D8E@dynamicsoft.com> Date: Sun, 27 Jan 2002 13:28:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: De Leo Walter CC: "'sip@ietf.org'" References: <19364262E259D51198BA0008C7E6528E091B82@MSTELEFONICA8> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: draft-rosenberg-sip-app-components-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit De Leo Walter wrote: > > As this draft has expired I'd like to know if there is a new version in > the > oven or it has been renamed or let die. Although there appears to be much interest in this work, it is not one the charter of sip or sipping at this time. I may rev it to keep it alive for reference, but chartered items take higher precedence for me right now. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 27 13:52:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02167 for ; Sun, 27 Jan 2002 13:52:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21334 for sip-archive@odin.ietf.org; Sun, 27 Jan 2002 13:52:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21006; Sun, 27 Jan 2002 13:33:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA20937 for ; Sun, 27 Jan 2002 13:33:41 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02035; Sun, 27 Jan 2002 13:33:38 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0RIWs6Y001849; Sun, 27 Jan 2002 13:32:54 -0500 (EST) Message-ID: <3C5447AF.4B48DED8@dynamicsoft.com> Date: Sun, 27 Jan 2002 13:32:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: John.Hearty@Level3.com, huitema@windows.microsoft.com, jh@lohi.eng.song.fi, dean.willis@softarmor.com, sipping@ietf.org, mwatson@nortelnetworks.com, Sip@ietf.org Subject: Re: [Sip] Re: [Sipping] calling number blocking at sip/isup gateway References: <3C51F646.1AB8DDE0@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > >>These are just some thoughts, so please don't flame me :) > >> > >>There was once a discussion (open issue #140) if the whole of the To- > >>and From headers, or only the tag, should be used as call-leg/dialog > >>identifiers. > >> > >>The decission was that they should. > >> > >>So, ASSUMING that ONLY the tags of the To- and From headers were used > >>for the dialog identifier, I guess it wouldn't matter if proxy would > >>modify the SIP-URI part of the To- and From headers? So, the question > >>is: would that make the problem we are discussing here any easier? > > > >Sounds dangerous for backward compatibility, as most UAs out there > still > >use these headers to ID the session. > > Well, the UAS would always see the same header values. And, if the proxy > which changes the headers also inserts itself in the route, it could > always by default change the headers back when sending a message > (request or reply) to the UAC, so the header values between the UAC and > that proxy would also always be the same. Sounds like a B2BUA, which is what I proposed to Juha would be needed for this particular problem. The proxy/b2bua HAS to modify all messages, not just for dialog matching, but for privacy! If it modifies the From only in the INVITE, but the BYE contains the original From field, privacy has been compromised. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 27 14:05:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02314 for ; Sun, 27 Jan 2002 14:05:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22083 for sip-archive@odin.ietf.org; Sun, 27 Jan 2002 14:05:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21232; Sun, 27 Jan 2002 13:45:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21206 for ; Sun, 27 Jan 2002 13:45:30 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02101 for ; Sun, 27 Jan 2002 13:45:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0RIjc6Y001856; Sun, 27 Jan 2002 13:45:38 -0500 (EST) Message-ID: <3C544AA9.BD5B9A7F@dynamicsoft.com> Date: Sun, 27 Jan 2002 13:44:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] Re: Unify draft and 1-of-N References: <200201251856.NAA93476@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > Alan Johnston wrote: > > Bill Marshall wrote: > > > I'm very concerned about the call flow shown in section 5.1 > > > of the unify draft, which does codec negotiation through the > > > use of a Re-INVITE. > > > > > > The main problem is the resulting post-pickup delay. When > > > more than a few hundred milliseconds, it results in a failed > > > call (from the user's view) and a completed billable call > > > (from the provider's view). Not a happy situation, > > > especially if it occurs on every call attempt. Retraining > > > the users is hardly an option. > > > > No - this is not a problem. If I send an INVITE listing three codecs > > then I must be prepared to receive media from any of those codecs. > Once > > the first media packet arrives, I load that codec and the call > proceeds. > > But the problem is that 5.1 sent an INVITE listing all as a=inactive, so > the UAC is not preparing to receive any media at all. It is not until > the > second INVITE (after the called party has answered) that any receive > ports are assigned. This is what causes the extreme post-pickup delay. > > While I recognize that this call flow is perfectly legitimate in 2543 > as well as bis, it has certain problems and should not be considered > as solving anything. Fair enough. I think that Alan's alternative, of instead loading the first codec received, and then immediately re-inviting to prevent a change, is probably better. In either case, bis is not going to contain any flows for "1 of N negotiation", since that kind of stuff is in offer/answer. I wasn't planning on putting this in offer/answer either. To be honest, the nice thing about the current offer/answer is that a UA can use either the a=inactive or load-first-codec appraoch, without interoperability issues, so long as the other side is offer/answer and bis compliant. Thus, someone who NEEDS 0% risk of a codec change can use a=inactive, most would use something like what Alan has suggested. A FAQ or something could document the various ways to solve these problems depending on the constraints of your system. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 27 14:10:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02406 for ; Sun, 27 Jan 2002 14:10:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22161 for sip-archive@odin.ietf.org; Sun, 27 Jan 2002 14:10:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21379; Sun, 27 Jan 2002 13:53:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21351 for ; Sun, 27 Jan 2002 13:53:28 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02190 for ; Sun, 27 Jan 2002 13:53:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0RIr66Y001859; Sun, 27 Jan 2002 13:53:06 -0500 (EST) Message-ID: <3C544C69.6EEB4AB2@dynamicsoft.com> Date: Sun, 27 Jan 2002 13:52:25 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] Open Issue #366: sip v. tel URL References: <3C517D30.EF110940@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Jonathan Rosenberg wrote: > > > > Henning Schulzrinne wrote: > > > > > > I agree, except that "support" may simply mean to return 606 or 486. > > > > That won't help, unless we mandate that clients retry with a SIP URL. > > There are only two choices that I can see: > > 1) The proxy at hotel.com translates tel:7 into sip:something@hotel.com > and then routes it. > > 2) The proxy knows that it can't handle telephone numbers, and has to do > something. One alternative is to say that the proxy should do a > mechanical translation into sip:@localdomain and then normal > behavior (404) kicks in if this is not a valid entry. The other is to > return an error and it would be up to the user or UA implementation to > try the sip variant. If its doing this mechanism translation already, that to me is the same as understanding what to do with a tel URL. > > > > > > There is no obligation for every proxy to have a PSTN gateway. > > > > It has nothing to do with PSTN; consider Dean's "7 for housekeeping > > scenario", where the UA inserts tel:7. > > I suppose if the hotel has SIP phones and says "dial 7", it has the > necessary plumbing in place to make this happen. If the number is > printed on the bedside phone, but Dean dials it from the SIP phone he > carries in his pocket, the rules above might rationalize the behavior. > >From a guest phone, some amount of surprise is unavoidable - after all, > dialing 7 on my mobile phone when in the hotel doesn't get me > housekeeping, either. The problem, more likely, is in an enterprise or service provider network, where people use whatever sip phone they like. Some phones may always use tel URL, other sip, and an arbitrary sip proxy would not work for those UA which use the tel URL. > > > > > > The user > > > can then specify a suitable sip:@domain to place the call. > > > > The user, or the UA? This seems a burden for the user. I think they > will > > view it as a system failure if they type something into their SIP > phone > > and it never works, because their proxy doesn't support tel URL. > > That's why we need either automatic translation (which is easy enough to > support so that there's no excuse) or an explicit error code. OK. Since we are out of time, and this is a minor point now, I will add an explicit error code for "URI Scheme Not Supported", so that the UA can retry with an alternate scheme. I'll add the appropriate discussion as well. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 27 15:18:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03013 for ; Sun, 27 Jan 2002 15:18:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24030 for sip-archive@odin.ietf.org; Sun, 27 Jan 2002 15:18:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23141; Sun, 27 Jan 2002 14:47:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23079 for ; Sun, 27 Jan 2002 14:47:31 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02675; Sun, 27 Jan 2002 14:47:25 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0RJlB111987; Sun, 27 Jan 2002 20:47:15 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0RJl2r6017146; Sun, 27 Jan 2002 21:47:02 +0200 (EET) Message-ID: <3C54593A.20D579B1@lmf.ericsson.se> Date: Sun, 27 Jan 2002 21:47:06 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: John.Hearty@Level3.com, huitema@windows.microsoft.com, jh@lohi.eng.song.fi, dean.willis@softarmor.com, sipping@ietf.org, mwatson@nortelnetworks.com, Sip@ietf.org Subject: Re: [Sip] Re: [Sipping] calling number blocking at sip/isup gateway References: <3C51F646.1AB8DDE0@lmf.ericsson.se> <3C5447AF.4B48DED8@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>>>These are just some thoughts, so please don't flame me :) >>>> >>>>There was once a discussion (open issue #140) if the whole of the To- >>>>and From headers, or only the tag, should be used as call-leg/dialog >>>>identifiers. >>>> >>>>The decission was that they should. >>>> >>>>So, ASSUMING that ONLY the tags of the To- and From headers were used >>>>for the dialog identifier, I guess it wouldn't matter if proxy would >>>>modify the SIP-URI part of the To- and From headers? So, the question >>>>is: would that make the problem we are discussing here any easier? >>> >>>Sounds dangerous for backward compatibility, as most UAs out there >>still >>>use these headers to ID the session. >> >>Well, the UAS would always see the same header values. And, if the proxy >>which changes the headers also inserts itself in the route, it could >>always by default change the headers back when sending a message >>(request or reply) to the UAC, so the header values between the UAC and >>that proxy would also always be the same. > >Sounds like a B2BUA, which is what I proposed to Juha would be needed >for this particular problem. Well, one could argue you don't have to call it that, since the modified parts (the SIP-URI) would not be part of the dialog identifier (which would be the To- and From header TAGS, and Call-ID) >The proxy/b2bua HAS to modify all messages, not just for dialog matching, but for privacy! Yes, that was my idea (if it only modifies the INVITE there would be backward compability issues which nodes still using the WHOLE From header, and not only the tag, as dialog identifier). Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Sun Jan 27 17:20:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04093 for ; Sun, 27 Jan 2002 17:20:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA28010 for sip-archive@odin.ietf.org; Sun, 27 Jan 2002 17:20:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26946; Sun, 27 Jan 2002 16:54:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26890 for ; Sun, 27 Jan 2002 16:54:52 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03902; Sun, 27 Jan 2002 16:54:49 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0RLsbb15828; Sun, 27 Jan 2002 15:54:37 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Sun, 27 Jan 2002 15:54:37 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE30@VA02> From: "Peterson, Jon" To: "'Juha Heinanen'" , sipping@ietf.org, "'sip@ietf.org'" Date: Sun, 27 Jan 2002 15:54:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [Sipping] calling number blocking at sip/isup gateway Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org What a long thread. The SIP-ISUP mapping draft suggests that if a telephone number is not available in the From field of an INVITE received by a gateway (either because the address in the From field is a SIP URI without telephone number syntax, or if some sort of 'Anonymous' value is present for privacy reasons), then the Calling Party Number (CgPN) parameter in ISUP should be excluded when a corresponding IAM is sent to the PSTN. This mapping is recommended because the CgPN parameter is not a mandatory parameter in the IAM. Similarly, an originating telephone number is not required to construct a SIP message. As Juha points out later in this thread, many nationalities require the presence of the CgPN parameter in IAMs. In the USA, for example, the CgPN must be sent over certain types of trunks - though not all, as it happens. Important exceptions are made in the USA (and elsewhere, I'm sure) for cases in which ISUP is interworking with another protocol (like old-school MF signaling). International calls routinely do not provide any information about the caller. Similar exceptions apply to certain PBXs that do not possess detailed information about the originator of a call (this is directly analogous to Dean's SIP gateway). In short, anyone reading this thread who believes that an ISUP network is going to break if you send an IAM without a CgPN from a gateway should really talk to some operations people at a major carrier - or look at how many times 'unavailable' shows up on their own Caller-ID screen. I believe that it is perfectly reasonable to look at a SIP-ISUP gateway as another case along these lines: SIP is substantially a different protocol, and sometimes SIP requests just don't have a Calling Party's Number - irregardless of any privacy concerns. No generic mechanism can assume that there is some 'correct' telephone number that must be associated with a client. Compensating for this fact by requiring gateways to insert some 'gateway number' in the CgPN is a hack that doesn't assist procedures like malicious call trace in any obvious way, and it is a hack that is also forbidden by some interconnection agreements in the USA on account of its use in grey-legal arbitrage scams. So in short, at a protocol level I think it is reasonable for the user's omission of a 'telephony' identity in the From field (either because they don't have one or for privacy reasons) to be communicated directly to the PSTN through the omission of the CgPN. At a policy level, I think gateway operators would be well advised to cryptographically authenticate users, and record session parameters in order to provide sufficient data for abuse and fraud detection. I mean, gateway operators could, if they were so inclined, reject requests that don't have an originating 'telephony' identity, or even a specific telephone number in the From field. However, this is quite plainly orthogonal to the SIP-ISUP mapping process. The mapping described in the SIP-ISUP draft is designed to work regardless of whether the call originated at a network-controlled gateway or a user-controlled client. Note (following Matt Holdrege) that if the session originates in the ISUP world, then RFC3204 can be used to carry the original CgPN information with any necessary parameters regarding presentation so that an IAM can be appropriately constructed when a request returns to the PSTN. If a call originates and terminates in the PSTN, then I think callers (and network operators) will expect that the PSTN privacy features will work - and I believe SIP-T satisfies that expectation. As a design goal, SIP-T does not require any extensions to SIP or ISUP - it tries to explain how you map the two protocols, not how you turn one into the other. Initiatives other than SIP-T have attempted to demonstrate how to make SIP, with extensions, a functional superset of the PSTN (the sip-privacy draft clearly comes from that line of thinking). I agree with a number of the respondents (including Christian) that this is actually very difficult to do, and I maintain that the more modest SIP-T practice is sufficient to interwork with the PSTN as I understand it. Finally, the SIP-ISUP mapping draft does explicitly note that implementers could make use of a generic SIP privacy mechanism - however, as I've argued in the past, I'm not sure that one is currently on the table. I do agree that there should be one. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.song.fi] > Sent: Wednesday, January 23, 2002 10:14 AM > To: sipping@ietf.org > Subject: [Sipping] calling number blocking at sip/isup gateway > > > i didn't find from draft-ietf-sipping-isup-00.txt, how should sip > originated invite look like in order to prevent the called pstn party > from seeing the calling sip party's number in the from field of the > invite. > > can a proxy add something to the invite on behalf of the calling sip > user in order to get the calling number blocked by the sip/isup gw? > > -- juha > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 07:09:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22872 for ; Mon, 28 Jan 2002 07:09:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA06266 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 07:09:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04310; Mon, 28 Jan 2002 06:23:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04279 for ; Mon, 28 Jan 2002 06:23:06 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22246 for ; Mon, 28 Jan 2002 06:23:04 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0SBMi6Y002807; Mon, 28 Jan 2002 06:22:44 -0500 (EST) Message-ID: <3C55345D.DC5A4FEE@dynamicsoft.com> Date: Mon, 28 Jan 2002 06:22:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] bis-06 now available! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I have just submitted an update to bis. Until it appears in the archives, you can pick it up at: http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.txt http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.ps http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.pdf or http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-06.txt http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-06.ps http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-06.pdf This revision incorporates pretty much all of the comments we received on bis-05, and brings to resolution nearly all of the open issues logged against bis. To my knowledge, it also incorporates all questions, comments, and clarifications requested on sip, sipping, and sip-implementors from June 2001 till now. We still need to work through the loose routing and herfp stuff some more, and so I expect that to change between this version and bis-07 (which we plan on issuing within one week). However, I think this is in excellent shape, and I am quite confident that we are very near the finish line. We worked hard to track the changes, there are changebars and an extensive changes in -06 section. Please do note the #1 item, which was that TCP is now mandatory on all elements, due to our solution for bug #184 for large messages. Comments, questions, and criticisms (and I'm sure people will have them) are welcome. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 10:11:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28616 for ; Mon, 28 Jan 2002 10:11:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15996 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 10:11:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14941; Mon, 28 Jan 2002 09:50:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14912 for ; Mon, 28 Jan 2002 09:50:53 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27959 for ; Mon, 28 Jan 2002 09:50:48 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 28 Jan 2002 14:51:15 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Jan 2002 14:51:50 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <45730E094814E44488F789C1CDED27AEC55285@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: S/MIME, Authentication and Integrity Thread-Index: AcGoC1GIE9w9+idbQLGwfZGCvNeNlw== From: "James Undery" To: "SIP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA14913 Subject: [Sip] S/MIME, Authentication and Integrity Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Looking over section 21.4.1 I am having trouble seeing how any of the claims can be justified against a MiTM attack. Without a challange/credentials framework S/MIME can't offer Authentication or Integrity e.g. a MiTM just removes the S/MIME protection (and optionally adds it's own). 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 daemon@optimus.ietf.org Mon Jan 28 11:55:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02297 for ; Mon, 28 Jan 2002 11:55:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22138 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 11:55:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20173; Mon, 28 Jan 2002 11:20:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20145 for ; Mon, 28 Jan 2002 11:20:04 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01295 for ; Mon, 28 Jan 2002 11:20:00 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 28 Jan 2002 16:20:28 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Jan 2002 16:21:00 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <45730E094814E44488F789C1CDED27AEC55286@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: new Register DoS attack Thread-Index: AcGoF8ZjK0hXonpdSeWedsnELdb/dA== From: "James Undery" To: "SIP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA20146 Subject: [Sip] new Register DoS attack Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, The recent (non normative) change to Registrar behaviour introduces a new DoS attack against the registering UAC. There are a number of variations of this attack, the attacker must be able to observe the UAC REGISTER and send a re-REGISTER with an incremented CSeq. Next time the UAC sends a REGISTER it will fail to update the bindings. The obvious and lazy extension to this attack is to increment the CSeq by a larger value (just within whatever a registrar will tolerate, bearing in mind Proxy-Authentication may increase the CSeq legitimately in steps larger than 1). 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 daemon@optimus.ietf.org Mon Jan 28 11:56:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02328 for ; Mon, 28 Jan 2002 11:56:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22190 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 11:56:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21208; Mon, 28 Jan 2002 11:35:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21177 for ; Mon, 28 Jan 2002 11:35:26 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01834 for ; Mon, 28 Jan 2002 11:35:23 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0SGZLb27704; Mon, 28 Jan 2002 11:35:23 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 10:35:20 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE36@VA02> From: "Peterson, Jon" To: "'James Undery'" , "SIP (E-mail)" Subject: RE: [Sip] S/MIME, Authentication and Integrity Date: Mon, 28 Jan 2002 10:35:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The attack is mentioned in 21.2, and discussed relatively extensively in 22.4.2. The basic jist of the text is that while the use of the S/MIME mechanism admits of the startup MiTM attack, it nevertheless improves the security of SIP. We contend that this isn't entirely dissimilar to the degree that SSH improves telnet security. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Monday, January 28, 2002 6:52 AM > To: SIP (E-mail) > Subject: [Sip] S/MIME, Authentication and Integrity > > > Hi, > > Looking over section 21.4.1 I am having trouble seeing how any of the > claims can be justified against a MiTM attack. Without a > challange/credentials framework S/MIME can't offer Authentication or > Integrity e.g. a MiTM just removes the S/MIME protection (and > optionally > adds it's own). > > 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 daemon@optimus.ietf.org Mon Jan 28 12:22:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03082 for ; Mon, 28 Jan 2002 12:22:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA24556 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 12:22:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23554; Mon, 28 Jan 2002 12:02:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23521 for ; Mon, 28 Jan 2002 12:02:17 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02513 for ; Mon, 28 Jan 2002 12:02:13 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 28 Jan 2002 17:02:41 UT content-class: urn:content-classes:message Subject: RE: [Sip] S/MIME, Authentication and Integrity MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 28 Jan 2002 17:03:17 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <45730E094814E44488F789C1CDED27AEC55287@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] S/MIME, Authentication and Integrity Thread-Index: AcGoGe3xHb6HEkBMQZCzDbDKOxvBoAAAk8Eg From: "James Undery" To: "Peterson, Jon" , "SIP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA23522 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit comments inline. > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > The attack is mentioned in 21.2, and discussed relatively > extensively in > 22.4.2. The replacement of a certificate is mentioned, the removal of certificates isn't. > The basic jist of the text is that while the use of the > S/MIME mechanism > admits of the startup MiTM attack, it nevertheless improves > the security of > SIP. We contend that this isn't entirely dissimilar to the > degree that SSH > improves telnet security. I'd agree it improves security, I'd just disagree it was anywhere near the amount SSH improves telnet. The reason for this is if I telnet to a machine I am much more likely to have obtained a reliable fingerprint/copy of the certificate for the machine. The other reason and the one that definately isn't addressed is the lack of framework for the key exchange, which SSH provides. James > > -----Original Message----- > > From: James Undery [mailto:jundery@ubiquity.net] > > Looking over section 21.4.1 I am having trouble seeing how > any of the > > claims can be justified against a MiTM attack. Without a > > challange/credentials framework S/MIME can't offer Authentication or > > Integrity e.g. a MiTM just removes the S/MIME protection (and > > optionally > > adds it's own). _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 12:46:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03785 for ; Mon, 28 Jan 2002 12:46:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA25997 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 12:46:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24126; Mon, 28 Jan 2002 12:12:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24101 for ; Mon, 28 Jan 2002 12:12:05 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02850 for ; Mon, 28 Jan 2002 12:12:01 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0SHBQr02681; Mon, 28 Jan 2002 11:11:26 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 11:11:25 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187874@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] solving early media, HERFP, and unifying manyfolks Date: Mon, 28 Jan 2002 11:11:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A81E.D72C6260" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A81E.D72C6260 Content-Type: text/plain; charset="iso-8859-1" Hi, Following are some of the comments on the unify draft: 1) The draft proposes a Reason header to carry the reason codes. There's also a sipfrag approach of carrying the an entire SIP request/response as a new Mime type. Should there be a single approach and if they must be different, what're the pros and cons of their usage? 2) Its not clear how the UA determines when to stop local ringing and await early media. Pre-bis05 drafts mentioned using SDP within 183 to indicate this to the UA. Does the UAC wait for a 1) new Offer, or 2) an Answer, to stop any local ringing that might be taking place. I guess the behavior would be same as for regular media, but it would help if this is clarified. 3) We support Rohan's proposal of using the new method UPDATE instead of reusing the COMET, as the semantics are significantly different than COMET. 4) Another concern is, from 3GPP perspective, if this draft is the replacement of manyfolks, then that calls for some major changes within the 3GPP specs. I do not support inclusion of this in the bis, but the bis should discuss these issues and refer to this draft as the solution & this draft should be progressed towards the last call ASAP. Regards, Sanjoy ================================ Carrier VoIP Group Nortel Networks Ph: 972-685-8274 (ESN: 445), Fax: 972-685-3813 Mobile: 972-571-2062 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, January 17, 2002 1:39 PM > To: sip@ietf.org; Jonathan Rosenberg > Subject: [Sip] solving early media, HERFP, and unifying manyfolks > > > Folks, > > I've been working on some of the open issues in bis, mainly > HERFP, the > usage of a three-way SDP exchange, overlapping INVITE, and > unification > of O/A with manyfolks. In the process, I came up with a joint > solution > to all of these problems. I have written it up, along with call flows > showing how it is used in all cases, in an I-D that I have just > submitted. Until that I-D appears, you may pick it up at: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt > > In summary, the draft proposes that COMET take on a new, much broader > definition, encompassing the semantics of UPDATE, and then > some, as has > been discussed on the list. The draft postulates how manyfolks can be > recast to fit within the offer/answer model, and then shows how COMET > can also be used to update not just session parameters, but > other state, > in an effort to resolve HERFP. For those confused about what > HERFP is, > it is a rather nasty forking problem that interferes with > services, it > is discussed in detail in the above draft. > > The proposal would change bis in a simple way, which is to generalize > the conditions under which SDP could appear in SIP. THis > generalization > would imply the current behavior (INV/200 or 200/ACK) for baseline > implementations, but would support richer exchanges for those > supporting > the new COMET. Furthermore, the draft proposes that manyfolks be > sufficiently generalized to provide this new form of COMET. > > I would also like to point out that dynamicsoft may have IPR against > this draft. I will say, honestly, that we have been forced into the > corner of making IPR claims against IETF documents due to the > existence > of claims against IETF documents that have been made by > others. However, > our aim is ONLY defensive. As such, I have worked with our > attorneys to > work out licensing terms which I think everyone will find most > agreeable, and indeed, laudable. They are: > > > > > dynamicsoft may seek patent protection on technology described in > documents which dynamicsoft submits for use in IETF standards > discussions. In relation to any IETF standard incorporating any such > technology, dynamicsoft will grant a royalty free > non-exclusive license > to Qualified Parties to utilize such technology if necessary for > practice of IETF standards implemented as a result of dynamicsoft's > submission. As used herein, Qualified Parties means a party who has > not, does not and will not assert, in litigation or > otherwise, including > in licensing discussions, any patent or other intellectual property > right against dynamicsoft. Any such license to a Qualified > Party shall > terminate at once if such party asserts a patent or other > intellectual > property right against dynamicsoft. dynamicsoft will grant > non-exclusive licenses to Non-Qualified Parties on reasonable, > reciprocal non-discriminatory terms and conditions. > > > These terms will also appear shortly on the IPR claims page > at the IETF > site. A summary of these terms is basically "leave us alone, > and this is > free". We feel that this is very much in the spirit of the IETF > practices and attitudes towards IPR, but recognizes that > companies have > a need to protect themselves. I would encourage others who > have IPR to > make their IPR available under similar terms, so we can focus on > technology work rather than acting as amateur lawyers. > > Comments and questions welcome, as always. > > -Jonathan R. > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > ------_=_NextPart_001_01C1A81E.D72C6260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] solving early media, HERFP, and unifying = manyfolks

Hi,

Following are some of the comments on the unify = draft:

1) The draft proposes a Reason header to carry the = reason codes. There's also a sipfrag approach of carrying the an entire = SIP request/response as a new Mime type. Should there be a single = approach and if they must be different, what're the pros and cons of = their usage?

2) Its not clear how the UA determines when to stop = local ringing and await early media. Pre-bis05 drafts mentioned using = SDP within 183 to indicate this to the UA. Does the UAC wait for a 1) = new Offer, or 2) an Answer, to stop any local ringing that might be = taking place. I guess the behavior would be same as for regular media, = but it would help if this is clarified.

3) We support Rohan's proposal of using the new = method UPDATE instead of reusing the COMET, as the semantics are = significantly different than COMET.

4) Another concern is, from 3GPP perspective, if this = draft is the replacement of manyfolks, then that calls for some major = changes within the 3GPP specs. I do not support inclusion of this in = the bis, but the bis should discuss these issues and refer to this = draft as the solution & this draft should be progressed towards the = last call ASAP.

Regards,
Sanjoy

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Carrier VoIP Group
Nortel Networks
Ph: 972-685-8274 (ESN: 445), Fax: = 972-685-3813
Mobile: 972-571-2062



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, January 17, 2002 1:39 PM
> To: sip@ietf.org; Jonathan Rosenberg
> Subject: [Sip] solving early media, HERFP, and = unifying manyfolks
>
>
> Folks,
>
> I've been working on some of the open issues in = bis, mainly
> HERFP, the
> usage of a three-way SDP exchange, overlapping = INVITE, and
> unification
> of O/A with manyfolks. In the process, I came = up with a joint
> solution
> to all of these problems. I have written it up, = along with call flows
> showing how it is used in all cases, in an I-D = that I have just
> submitted. Until that I-D appears, you may pick = it up at:
>
> http://www.jdrosen.net/papers/draft-rosenberg-sip-unif= y-00.txt
>
> In summary, the draft proposes that COMET take = on a new, much broader
> definition, encompassing the semantics of = UPDATE, and then
> some, as has
> been discussed on the list. The draft = postulates how manyfolks can be
> recast to fit within the offer/answer model, = and then shows how COMET
> can also be used to update not just session = parameters, but
> other state,
> in an effort to resolve HERFP. For those = confused about what
> HERFP is,
> it is a rather nasty forking problem that = interferes with
> services, it
> is discussed in detail in the above = draft.
>
> The proposal would change bis in a simple way, = which is to generalize
> the conditions under which SDP could appear in = SIP. THis
> generalization
> would imply the current behavior (INV/200 or = 200/ACK) for baseline
> implementations, but would support richer = exchanges for those
> supporting
> the new COMET. Furthermore, the draft proposes = that manyfolks be
> sufficiently generalized to provide this new = form of COMET.
>
> I would also like to point out that dynamicsoft = may have IPR against
> this draft. I will say, honestly, that we have = been forced into the
> corner of making IPR claims against IETF = documents due to the
> existence
> of claims against IETF documents that have been = made by
> others. However,
> our aim is ONLY defensive. As such, I have = worked with our
> attorneys to
> work out licensing terms which I think everyone = will find most
> agreeable, and indeed, laudable. They = are:
>
>
>
>
> dynamicsoft may seek patent protection on = technology described in
> documents which dynamicsoft submits for use in = IETF standards
> discussions.  In relation to any IETF = standard incorporating any such
> technology, dynamicsoft will grant a royalty = free
> non-exclusive license
> to Qualified Parties to utilize such technology = if necessary for
> practice of IETF standards implemented as a = result of dynamicsoft's
> submission.  As used herein, Qualified = Parties means a party who has
> not, does not and will not assert, in = litigation or
> otherwise, including
> in licensing discussions, any patent or other = intellectual property
> right against dynamicsoft.  Any such = license to a Qualified
> Party shall
> terminate at once if such party asserts a = patent or other
> intellectual
> property right against dynamicsoft.  = dynamicsoft will grant
> non-exclusive licenses to Non-Qualified Parties = on reasonable,
> reciprocal non-discriminatory terms and = conditions.
>
>
> These terms will also appear shortly on the IPR = claims page
> at the IETF
> site. A summary of these terms is basically = "leave us alone,
> and this is
> free". We feel that this is very much in = the spirit of the IETF
> practices and attitudes towards IPR, but = recognizes that
> companies have
> a need to protect themselves. I would encourage = others who
> have IPR to
> make their IPR available under similar terms, = so we can focus on
> technology work rather than acting as amateur = lawyers.
>
> Comments and questions welcome, as = always.
>
> -Jonathan R.
>
>
>
>
>
> --
> Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
> Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;      East Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;        FAX: (973) = 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sipping@ietf.org for new developments on = the application of sip
>

------_=_NextPart_001_01C1A81E.D72C6260-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 13:44:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05634 for ; Mon, 28 Jan 2002 13:44:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA28733 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 13:44:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27693; Mon, 28 Jan 2002 13:21:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA27664 for ; Mon, 28 Jan 2002 13:21:17 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04954 for ; Mon, 28 Jan 2002 13:21:15 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0SILFb08777; Mon, 28 Jan 2002 12:21:15 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 12:21:15 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE39@VA02> From: "Peterson, Jon" To: "'James Undery'" , "SIP (E-mail)" Subject: RE: [Sip] S/MIME, Authentication and Integrity Date: Mon, 28 Jan 2002 12:21:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org On removal of certificates, yes, I totally agree that's an omission. I thought we had some text about how to handle this (and a couple of similar cases, like what happens when S/MIME is unsupported by a recipient) but now I can't find it anywhere in the text. Hmm, been doing too much cut and paste lately to be sure. Well, it'll be added in the build next Monday. Removal is I think pretty easy to detect (easier that replacement), and it's fairly obvious what you should do in that case. The relatively 'likeliness' of having obtained a reliable fingerprint is debatable; there are certainly some people who use SSH that make sure to acquire an original fingerprint from the same LAN as the host in question before they go on a business trip or what have you. In some SIP architectures this certainty won't be achievable - but then again, in some it will be. Clearly there are all sorts of customary SIP intermediaries, such as proxy servers, that potentially have carte blanche to act as MiTMs which are not a concern in SSH. So I don't entirely disagree with you - but, that much said, I think it's pretty clear why we draw the analogy. Perhaps the most important similarity between the two is that the oversight of a human is required in trust establishment. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Monday, January 28, 2002 9:03 AM > To: Peterson, Jon; SIP (E-mail) > Subject: RE: [Sip] S/MIME, Authentication and Integrity > > > comments inline. > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > > The attack is mentioned in 21.2, and discussed relatively > > extensively in > > 22.4.2. > > The replacement of a certificate is mentioned, the removal of > certificates isn't. > > > The basic jist of the text is that while the use of the > > S/MIME mechanism > > admits of the startup MiTM attack, it nevertheless improves > > the security of > > SIP. We contend that this isn't entirely dissimilar to the > > degree that SSH > > improves telnet security. > > I'd agree it improves security, I'd just disagree it was anywhere near > the amount SSH improves telnet. The reason for this is if I > telnet to a > machine I am much more likely to have obtained a reliable > fingerprint/copy of the certificate for the machine. The other reason > and the one that definately isn't addressed is the lack of > framework for > the key exchange, which SSH provides. > > James > > > > -----Original Message----- > > > From: James Undery [mailto:jundery@ubiquity.net] > > > > Looking over section 21.4.1 I am having trouble seeing how > > any of the > > > claims can be justified against a MiTM attack. Without a > > > challange/credentials framework S/MIME can't offer > Authentication or > > > Integrity e.g. a MiTM just removes the S/MIME protection (and > > > optionally > > > adds it's own). > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 16:03:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08755 for ; Mon, 28 Jan 2002 16:03:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA05435 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 16:03:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04455; Mon, 28 Jan 2002 15:44:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04424 for ; Mon, 28 Jan 2002 15:44:47 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08317 for ; Mon, 28 Jan 2002 15:44:43 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0SKiFL20529 for ; Mon, 28 Jan 2002 12:44:15 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT59315; Mon, 28 Jan 2002 12:43:45 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA21088; Mon, 28 Jan 2002 12:44:15 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.47135.173002.664053@thomasm-u1.cisco.com> Date: Mon, 28 Jan 2002 12:44:15 -0800 (PST) To: sip@ietf.org In-Reply-To: <3C55345D.DC5A4FEE@dynamicsoft.com> References: <3C55345D.DC5A4FEE@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sip] TLS section Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit First of all, this section doesn't say what needs to be implemented. It's only of the form "if you use TLS, then you must do X." More comments on the actual text. "Transport or network layer security encrypts signaling traffic, guaranteeing message confidentiality and integrity (note however that the originator and recipient of a session may be deducible by observers performing a network traffic analysis). The certificates used to encrypt traffic can also be used to provide a means of authentication in many architectures." Certificates do nothing of the sort. They are used as a means of proving identity, pure and simple; they encrypt nothing. Key exchange is accomplished by other means; authentication only answers the question "who". Also: you are overloading the word encryption; separate out confidentiality and message integrity. "IPSec is a set of network-layer protocol tools that can collectively be used as a secure replacement for traditional IP (Internet Protocol). IPSec is most suited to architectures in which a set of SIP hosts (mingled user agents and proxy servers) or bridged administrative domains (possibly using security gateways) have an existing trust relationship with one another, although IPSec can also be used on a per-hop basis." The exact same thing can be said about TLS. You are not differentiating anything here, and if you think you are, you are mistaken. I suspect that there is some confusion about PKI's going on here. IPSec is generally implemented at an operating-system level within a host, and in many architectures it does not require integration with SIP applications. Any deployment of IPSec for SIP would require an IPSec profile describing the protocols tools that would be required to secure SIP and the modes in which they would operate. No such profile is given in this document. Please, this doesn't have to be hard. ESP RFC 2406 in transport mode with HMAC-MD-5-NULL should be all that needs to be supported to get interoperability. "TLS provides transport-layer security over connection-oriented protocols (for the purposes of this document, TCP); "tls" (signifying TLS over TCP) can be specified as the desired transport protocol within a Via header field or a SIP-URI. TLS is most suited to architectures in which a chain of trust joins together a set of hosts." Nonsense. TLS is used as a point to point protocol primarily, and *anything* can be used to ignore transitive trust problems. Again, you haven't differentiated anything. "For example, Alice trusts her local proxy server, which in turn trust Bob's local proxy server, which Bob trusts, hence Bob and Alice can communicate securely." This is a bug, not a feature. TLS must be tightly coupled with a SIP application. Note that transport mechanisms are specified on a hop-by-hop basis in SIP, and that in some deployments TLS might be used for only certain portions of the signaling path. ...and useless on the most vulerable part of the signaling path. When TLS is used in a SIP application, implementers MUST minimally support the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. For purposes of backwards compatibility, proxy servers, redirect servers and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other ciphersuite. Just as a general note, I object to anything which makes RSA/PKI a requirement for a UA. Also: this predictably ignores the real problem here which is UDP based UA's. 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 daemon@optimus.ietf.org Mon Jan 28 16:17:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09149 for ; Mon, 28 Jan 2002 16:17:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA05736 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 16:17:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04833; Mon, 28 Jan 2002 15:56:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04804 for ; Mon, 28 Jan 2002 15:56:06 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08495 for ; Mon, 28 Jan 2002 15:56:02 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0SKtYL29564 for ; Mon, 28 Jan 2002 12:55:34 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT59607; Mon, 28 Jan 2002 12:55:03 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA21093; Mon, 28 Jan 2002 12:55:33 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.47813.551042.630855@thomasm-u1.cisco.com> Date: Mon, 28 Jan 2002 12:55:33 -0800 (PST) To: sip@ietf.org In-Reply-To: <3C55345D.DC5A4FEE@dynamicsoft.com> References: <3C55345D.DC5A4FEE@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sip] TLS is not a "transport" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The bis-06 draft improperly conflates TLS with a transport protocol. This is incorret as it should be obvious if you want to use TLS over SCTP. Any conflation of this kind should be removed. HTTP got this wrong too. Better would be to have some sort of naming scheme which says: "SIP over transport protected by security protocol". 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 daemon@optimus.ietf.org Mon Jan 28 16:19:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09226 for ; Mon, 28 Jan 2002 16:19:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA05784 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 16:19:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05415; Mon, 28 Jan 2002 16:02:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05384 for ; Mon, 28 Jan 2002 16:02:34 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08723 for ; Mon, 28 Jan 2002 16:02:29 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0SL22I25990 for ; Mon, 28 Jan 2002 13:02:02 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT59792; Mon, 28 Jan 2002 13:01:31 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA21096; Mon, 28 Jan 2002 13:02:01 -0800 (PST) Date: Mon, 28 Jan 2002 13:02:01 -0800 (PST) Message-Id: <200201282102.NAA21096@thomasm-u1.cisco.com> From: Michael Thomas To: sip@ietf.org X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Subject: [Sip] SIP and PKI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org bis-06 implies very strongly that SIP elements should use PKI based authentication. This should be removed. There are other means of authentication -- even within IETF -- and SIP shouldn't be picking winners, especially when there is absolutely no evidence that one is superior to the other in the field. Indeed, the evidence is that PKI's are *not* popular. 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 daemon@optimus.ietf.org Mon Jan 28 16:41:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09592 for ; Mon, 28 Jan 2002 16:41:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA06749 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 16:41:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05953; Mon, 28 Jan 2002 16:20:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05846 for ; Mon, 28 Jan 2002 16:20:37 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09267 for ; Mon, 28 Jan 2002 16:20:32 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0SLKMb32550; Mon, 28 Jan 2002 16:20:27 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 15:20:21 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE46@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] TLS section Date: Mon, 28 Jan 2002 15:20:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks for your comments, Mike. You always bring such a lively spirit of debate to this otherwise dull standards process. Some notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, January 28, 2002 12:44 PM > To: sip@ietf.org > Subject: [Sip] TLS section > > > > First of all, this section doesn't say what needs > to be implemented. It's only of the form "if you > use TLS, then you must do X." Yes, we moved that part down the street to 22.3.1. > > More comments on the actual text. > > "Transport or network layer security encrypts signaling traffic, > guaranteeing message confidentiality and integrity (note > however that > the originator and recipient of a session may be deducible by > observers performing a network traffic analysis). The certificates > used to encrypt traffic can also be used to provide a means of > authentication in many architectures." > > Certificates do nothing of the sort. They are used > as a means of proving identity, pure and simple; > they encrypt nothing. Key exchange is accomplished > by other means; authentication only answers the > question "who". Also: you are overloading the word > encryption; separate out confidentiality and > message integrity. Are you honestly suggesting that certificates cannot be used to provide a means of authentication in many architectures? Distinguishing 'proving identity' from 'authenticating' is perhaps a little more rigorous than I'm accustomed to, I'm afraid. It's true that 'encryption' isn't terribly precise here, though. Still, I doubt anyone reading this would be at all confused by it. > > "IPSec is a set of network-layer protocol tools that can > collectively > be used as a secure replacement for traditional IP (Internet > Protocol). IPSec is most suited to architectures in which a set of > SIP hosts (mingled user agents and proxy servers) or bridged > administrative domains (possibly using security gateways) have an > existing trust relationship with one another, although > IPSec can also > be used on a per-hop basis." > > The exact same thing can be said about TLS. You > are not differentiating anything here, and if you > think you are, you are mistaken. I suspect that > there is some confusion about PKI's going on here. TLS can be used as a replacement for traditional IP? Maybe using Mr. Bradners IP-over-HTTP draft, if we run it over TLS. TLS has security gateways and VPNs? > > IPSec is generally implemented at an operating-system > level within a > host, and in many architectures it does not require > integration with > SIP applications. Any deployment of IPSec for SIP would require an > IPSec profile describing the protocols tools that would be required > to secure SIP and the modes in which they would operate. No such > profile is given in this document. > > Please, this doesn't have to be hard. ESP RFC 2406 > in transport mode with HMAC-MD-5-NULL should be > all that needs to be supported to get > interoperability. I'm not sure this is sufficient; most of the other advocates of IPSec seem to want some sort of security gateway solution. I think we should shake this out somewhere other than bis. > > "TLS provides transport-layer security over connection-oriented > protocols (for the purposes of this document, TCP); "tls" > (signifying > TLS over TCP) can be specified as the desired transport protocol > within a Via header field or a SIP-URI. TLS is most suited to > architectures in which a chain of trust joins together a set of > hosts." > > Nonsense. TLS is used as a point to point protocol > primarily, and *anything* can be used to ignore > transitive trust problems. Again, you haven't > differentiated anything. A spoon is more suitable for eating soup than a fork, but I'm sure that you could make the fork work if you tried hard enough. I believe that TLS is more suitable for certain architectures than IPSec, and vice versa. > > "For example, Alice trusts her local proxy server, which in > turn trust Bob's local proxy server, which Bob trusts, > hence Bob and > Alice can communicate securely." > > This is a bug, not a feature. The security solutions section, 22.3.2, suggests a way that this transitivity might be used in a real-life deployment. Although it's distasteful to you, I think it jibes with the core needs of SIP. > > TLS must be tightly coupled with a SIP application. Note that > transport mechanisms are specified on a hop-by-hop basis > in SIP, and > that in some deployments TLS might be used for only > certain portions > of the signaling path. > > ...and useless on the most vulerable part of the > signaling path. Useless for UDP, it's true. The utility of UDP is also open for debate, though. > > When TLS is used in a SIP application, implementers MUST minimally > support the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. For > purposes of > backwards compatibility, proxy servers, redirect servers and > registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. > Implementers > MAY also support any other ciphersuite. > > Just as a general note, I object to anything which > makes RSA/PKI a requirement for a UA. Noted. > > Also: this predictably ignores the real problem > here which is UDP based UA's. I believe TCP is now mandatory for UAs. Sorry to be so predictable. > > 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 daemon@optimus.ietf.org Mon Jan 28 17:49:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10532 for ; Mon, 28 Jan 2002 17:49:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09181 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 17:49:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08289; Mon, 28 Jan 2002 17:27:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08252 for ; Mon, 28 Jan 2002 17:27:06 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10201 for ; Mon, 28 Jan 2002 17:27:01 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15965; Mon, 28 Jan 2002 17:26:32 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA29411; Mon, 28 Jan 2002 17:26:34 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Jan 2002 17:26:33 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57C84A@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Peterson, Jon'" , "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] TLS section Date: Mon, 28 Jan 2002 17:26:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm curious about the following: > > ................ Any deployment of IPSec for SIP would > require an > > IPSec profile describing the protocols tools that would > be required > > to secure SIP and the modes in which they would operate. No such > > profile is given in this document. > > > > Please, this doesn't have to be hard. ESP RFC 2406 > > in transport mode with HMAC-MD-5-NULL should be > > all that needs to be supported to get > > interoperability. > > I'm not sure this is sufficient; most of the other advocates > of IPSec seem > to want some sort of security gateway solution. I think we > should shake this > out somewhere other than bis. Can we see some comments from IPSec advocates whether a MUST IMPLEMENT for transport mode with HMAC-MD-5-NULL is acceptable? Brian *********This message is definately not confidential and it does not matter in practice who sees it and whether or not it goes astray. No harm whatever would come to anyone even if it were published in a national newspaper. I apologise therefore for the unnecessary and irritating message that may or may not follow (I don't know because it is invisible to me)!!!!****** This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachment, use the contents for any purposes, or disclose the contents to any other person: to do so could be a breach of confidence. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 17:54:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10618 for ; Mon, 28 Jan 2002 17:54:46 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09230 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 17:54:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08788; Mon, 28 Jan 2002 17:32:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08758 for ; Mon, 28 Jan 2002 17:32:11 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10290 for ; Mon, 28 Jan 2002 17:32:04 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0SMVVI03675; Mon, 28 Jan 2002 14:31:31 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT62355; Mon, 28 Jan 2002 14:31:00 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA21112; Mon, 28 Jan 2002 14:31:30 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.53570.476636.906564@thomasm-u1.cisco.com> Date: Mon, 28 Jan 2002 14:31:30 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] TLS section In-Reply-To: <70565611B164D511957A001083FCDD56CAAE46@VA02> References: <70565611B164D511957A001083FCDD56CAAE46@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > > First of all, this section doesn't say what needs > > to be implemented. It's only of the form "if you > > use TLS, then you must do X." > > Yes, we moved that part down the street to 22.3.1. I noticed that later. It's a bit odd to have two sections. > > "Transport or network layer security encrypts signaling traffic, > > guaranteeing message confidentiality and integrity (note > > however that > > the originator and recipient of a session may be deducible by > > observers performing a network traffic analysis). The certificates > > used to encrypt traffic can also be used to provide a means of > > authentication in many architectures." > > > > Certificates do nothing of the sort. They are used > > as a means of proving identity, pure and simple; > > they encrypt nothing. Key exchange is accomplished > > by other means; authentication only answers the > > question "who". Also: you are overloading the word > > encryption; separate out confidentiality and > > message integrity. > > Are you honestly suggesting that certificates cannot be used to provide a > means of authentication in many architectures? Distinguishing 'proving > identity' from 'authenticating' is perhaps a little more rigorous than I'm > accustomed to, I'm afraid. That's not what the text says. The text says that certificates are used to encrypt traffic. That's incorrect. > It's true that 'encryption' isn't terribly precise here, though. Still, I > doubt anyone reading this would be at all confused by it. I find it confusing because it's not correct in a pretty large way. That is, reading this tells me that the authors (maybe you! :) are conflating message integrity/encryption with credentials. > > "IPSec is a set of network-layer protocol tools that can > > collectively > > be used as a secure replacement for traditional IP (Internet > > Protocol). IPSec is most suited to architectures in which a set of > > SIP hosts (mingled user agents and proxy servers) or bridged > > administrative domains (possibly using security gateways) have an > > existing trust relationship with one another, although > > IPSec can also > > be used on a per-hop basis." > > > > The exact same thing can be said about TLS. You > > are not differentiating anything here, and if you > > think you are, you are mistaken. I suspect that > > there is some confusion about PKI's going on here. > > TLS can be used as a replacement for traditional IP? Maybe using Mr. > Bradners IP-over-HTTP draft, if we run it over TLS. No. The paragraph implies that IPsec's applicability is limited to localized domains. TLS is just as limited insofar as the both imply PKI's. If you can build a large PKI at all, you could do it equally easy with IPsec as TLS. Thus this is not a differentiator. Frankly, I'd give up any other distinction than the two obvious ones: o IPsec allows use of UDP o TLS currently has an API to access the credentials, while IPsec requires that API to be built. > > Please, this doesn't have to be hard. ESP RFC 2406 > > in transport mode with HMAC-MD-5-NULL should be > > all that needs to be supported to get > > interoperability. > > I'm not sure this is sufficient; most of the other advocates of IPSec seem > to want some sort of security gateway solution. I think we should shake this > out somewhere other than bis. Huh? Nothing prevents them from doing that; in fact, it's probably happening today for anybody with an IPsec VPN from work. Transport mode IPsec is a host-host protocol. I don't think we need to consider anything else. > > Nonsense. TLS is used as a point to point protocol > > primarily, and *anything* can be used to ignore > > transitive trust problems. Again, you haven't > > differentiated anything. > > A spoon is more suitable for eating soup than a fork, but I'm sure that you > could make the fork work if you tried hard enough. > > I believe that TLS is more suitable for certain architectures than IPSec, > and vice versa. You haven't enumerated why. Given the language in the previous paragraphs I think there's a disconnect about what the fundamental problem for large scale deployments of security is (aside from the accidental). That is, wide-scale authentication is hard. TLS does not help or hurt here. Nor IPsec. They are just transport mechanisms which use the same authentication technology. > > "For example, Alice trusts her local proxy server, which in > > turn trust Bob's local proxy server, which Bob trusts, > > hence Bob and > > Alice can communicate securely." > > > > This is a bug, not a feature. > > The security solutions section, 22.3.2, suggests a way that this > transitivity might be used in a real-life deployment. Although it's > distasteful to you, I think it jibes with the core needs of SIP. We all know how to ignore the transitive problem. That's as simple as ignoring it. The other problem with this paragraph is that it implies there's some quantifiable difference between TLS or IPsec here. There isn't; neither can help you, nor will they impede your memory cells from losing all knowledge of the transitive trust problem. > > Also: this predictably ignores the real problem > > here which is UDP based UA's. > > I believe TCP is now mandatory for UAs. Sorry to be so predictable. Nothing addresses security for UDP and thus the spec is incomplete. 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 daemon@optimus.ietf.org Mon Jan 28 17:57:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10648 for ; Mon, 28 Jan 2002 17:57:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA09307 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 17:57:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08208; Mon, 28 Jan 2002 17:26:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08179 for ; Mon, 28 Jan 2002 17:26:13 -0500 (EST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10194 for ; Mon, 28 Jan 2002 17:26:04 -0500 (EST) Received: from JMPOLK-W2K (ssh-sj1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA12707; Mon, 28 Jan 2002 14:25:27 -0800 (PST) Message-Id: <4.1.20020128161005.02da2788@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 28 Jan 2002 16:25:07 -0600 To: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu From: "James M. Polk" Subject: Re: [Sip] bis-06 now available! In-Reply-To: <3C55345D.DC5A4FEE@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1643865223==_.ALT" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --=====================_1643865223==_.ALT Content-Type: text/plain; charset="us-ascii" FYI I just downloaded the txt version from: >http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.txt and, maybe it's just me, but pages ~224-238 have too many characters per line on many of the lines. For example, line ~ 6 on page 226 ("user-unreserved") appears to be approximately 126 characters wide... many others are much wider than the typical ~76 characters per line. Don't know if this matters, but it seems odd... At 06:22 AM 1/28/2002 -0500, Jonathan Rosenberg wrote: >Folks, > >I have just submitted an update to bis. Until it appears in the >archives, you can pick it up at: > >http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.txt >http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.ps >http://www.cs.columbia.edu/~jdrosen/draft-ietf-sip-rfc2543bis-06.pdf > >or > >http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-06.txt >http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-06.ps >http://www.jdrosen.net/papers/draft-ietf-sip-rfc2543bis-06.pdf > > >This revision incorporates pretty much all of the comments we received >on bis-05, and brings to resolution nearly all of the open issues logged >against bis. To my knowledge, it also incorporates all questions, >comments, and clarifications requested on sip, sipping, and >sip-implementors from June 2001 till now. We still need to work through >the loose routing and herfp stuff some more, and so I expect that to >change between this version and bis-07 (which we plan on issuing within >one week). However, I think this is in excellent shape, and I am quite >confident that we are very near the finish line. > >We worked hard to track the changes, there are changebars and an >extensive changes in -06 section. Please do note the #1 item, which was >that TCP is now mandatory on all elements, due to our solution for bug >#184 for large messages. > >Comments, questions, and criticisms (and I'm sure people will have them) >are welcome. > >Thanks, >Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PH: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" James M. Polk Consulting Engineer Office of the CTO Cisco Systems 2200 East President George Bush Turnpike Richardson, TX 75082 USA w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1643865223==_.ALT Content-Type: text/html; charset="us-ascii"
FYI

I just downloaded the txt version from:

and, maybe it's just me, but pages ~224-238 have too many characters per line on many of the lines. For example, line ~ 6 on page 226 ("user-unreserved") appears to be approximately 126 characters wide... many others are much wider than the typical ~76 characters per line.

Don't know if this matters, but it seems odd...

At 06:22 AM 1/28/2002 -0500, Jonathan Rosenberg wrote:
>Folks,
>
>I have just submitted an update to bis. Until it appears in the
>archives, you can pick it up at:
>
>
>or
>
>
>
>This revision incorporates pretty much all of the comments we received
>on bis-05, and brings to resolution nearly all of the open issues logged
>against bis. To my knowledge, it also incorporates all questions,
>comments, and clarifications requested on sip, sipping, and
>sip-implementors from June 2001 till now. We still need to work through
>the loose routing and herfp stuff some more, and so I expect that to
>change between this version and bis-07 (which we plan on issuing within
>one week). However, I think this is in excellent shape, and I am quite
>confident that we are very near the finish line.
>
>We worked hard to track the changes, there are changebars and an
>extensive changes in -06 section. Please do note the #1 item, which was
>that TCP is now mandatory on all elements, due to our solution for bug
>#184 for large messages.
>
>Comments, questions, and criticisms (and I'm sure people will have them)
>are welcome.
>
>Thanks,
>Jonathan R.
>
>--
>Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
>Chief Scientist                         First Floor
>dynamicsoft                             East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
>http://www.jdrosen.net                  PH:  (973) 952-5000
>
>_______________________________________________
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip

*************************************
"People generally demand more respect for their own rights than they are willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1643865223==_.ALT-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 18:24:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11046 for ; Mon, 28 Jan 2002 18:24:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA10180 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 18:23:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09836; Mon, 28 Jan 2002 18:05:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09807 for ; Mon, 28 Jan 2002 18:05:50 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10735 for ; Mon, 28 Jan 2002 18:05:45 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA18991; Mon, 28 Jan 2002 18:05:16 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA06755; Mon, 28 Jan 2002 18:05:18 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Jan 2002 18:05:17 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57C84F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Peterson, Jon'" , "'Michael Thomas'" , "'sip@ietf.org'" Subject: RE: [Sip] TLS section Date: Mon, 28 Jan 2002 18:05:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I've been asked to state what my own views on this question are. The answer is that while I would prefer tunnel mode be the MUST IMPLEMENT, I'll deal with transport as the minimum needed for interoperability. In our own systems, we will use tunnel mode most often. HMAC-MD-5-NULL is acceptable. I'd like to see a SHOULD with real crypto, but we may have difficulty agreeing on some of the choices. Brian > -----Original Message----- > From: Rosen, Brian > Sent: Monday, January 28, 2002 5:27 PM > To: 'Peterson, Jon'; 'Michael Thomas'; sip@ietf.org > Subject: RE: [Sip] TLS section > > > I'm curious about the following: > > > ................ Any deployment of IPSec for SIP would > > require an > > > IPSec profile describing the protocols tools that would > > be required > > > to secure SIP and the modes in which they would > operate. No such > > > profile is given in this document. > > > > > > Please, this doesn't have to be hard. ESP RFC 2406 > > > in transport mode with HMAC-MD-5-NULL should be > > > all that needs to be supported to get > > > interoperability. > > > > I'm not sure this is sufficient; most of the other advocates > > of IPSec seem > > to want some sort of security gateway solution. I think we > > should shake this > > out somewhere other than bis. > > Can we see some comments from IPSec advocates whether a > MUST IMPLEMENT for transport mode with HMAC-MD-5-NULL > is acceptable? > > Brian > > *********This message is definately not confidential and it does > not matter in practice who sees it and whether or not it goes > astray. No > harm whatever would come to anyone even if it were published in a > national newspaper. I apologise therefore for the unnecessary and > irritating message that may or may not follow (I don't know > because it is > invisible to me)!!!!****** > This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachment, use the contents for any purposes, or disclose the contents to any other person: to do so could be a breach of confidence. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 18:53:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11478 for ; Mon, 28 Jan 2002 18:53:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA11443 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 18:54:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10318; Mon, 28 Jan 2002 18:28:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10287 for ; Mon, 28 Jan 2002 18:28:12 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11110 for ; Mon, 28 Jan 2002 18:28:09 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0SNOOb02675; Mon, 28 Jan 2002 18:24:24 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 17:24:23 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE49@VA02> From: "Peterson, Jon" To: "'Rosen, Brian'" , "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] TLS section Date: Mon, 28 Jan 2002 17:24:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks Brian, I'm actually really interested in this topic as well. I think it would be interesting first to learn who on this distribution prefers to provide lower-layer security for SIP with IPSec rather than TLS, and then moreover whether those that do prefer IPSec would rather use transport mode (host-by-host, integrated with SIP applications) or tunnel mode (not integrated with SIP applications, using security gateways). Just to be clear about a couple of things surrounding this proposed IPSec profile: - Can we spell out a bit what we mean by HMAC-MD5-NULL? The string doesn't appear in 2406, anyway. For example, is the NULL for authentication, or encryption, or both? - Will implementations supporting this profile by be compliant with the minimum conformance requirements in rfc2406 section 5? - This assumes pre-shared keys, and entails no key exchange capabilities (i.e. IKE), right? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Monday, January 28, 2002 2:27 PM > To: 'Peterson, Jon'; 'Michael Thomas'; sip@ietf.org > Subject: RE: [Sip] TLS section > > > I'm curious about the following: > > > ................ Any deployment of IPSec for SIP would > > require an > > > IPSec profile describing the protocols tools that would > > be required > > > to secure SIP and the modes in which they would > operate. No such > > > profile is given in this document. > > > > > > Please, this doesn't have to be hard. ESP RFC 2406 > > > in transport mode with HMAC-MD-5-NULL should be > > > all that needs to be supported to get > > > interoperability. > > > > I'm not sure this is sufficient; most of the other advocates > > of IPSec seem > > to want some sort of security gateway solution. I think we > > should shake this > > out somewhere other than bis. > > Can we see some comments from IPSec advocates whether a > MUST IMPLEMENT for transport mode with HMAC-MD-5-NULL > is acceptable? > > Brian > > *********This message is definately not confidential and it does > not matter in practice who sees it and whether or not it goes > astray. No > harm whatever would come to anyone even if it were published in a > national newspaper. I apologise therefore for the unnecessary and > irritating message that may or may not follow (I don't know > because it is > invisible to me)!!!!****** > > > This e-mail and any attachments are confidential. If you are not the > intended recipient, please notify us immediately by reply > e-mail and then > delete this message from your system. Do not copy this e-mail or any > attachment, use the contents for any purposes, or disclose > the contents to > any other person: to do so could be a breach of confidence. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 19:03:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11615 for ; Mon, 28 Jan 2002 19:03:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA12128 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 19:03:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11064; Mon, 28 Jan 2002 18:39:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11000 for ; Mon, 28 Jan 2002 18:39:15 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11284 for ; Mon, 28 Jan 2002 18:39:11 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0SNchI23632; Mon, 28 Jan 2002 15:38:43 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT64407; Mon, 28 Jan 2002 15:38:11 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA21129; Mon, 28 Jan 2002 15:38:41 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.57601.150349.426343@thomasm-u1.cisco.com> Date: Mon, 28 Jan 2002 15:38:41 -0800 (PST) To: "Peterson, Jon" Cc: "'Rosen, Brian'" , "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] TLS section In-Reply-To: <70565611B164D511957A001083FCDD56CAAE49@VA02> References: <70565611B164D511957A001083FCDD56CAAE49@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > Thanks Brian, I'm actually really interested in this topic as well. > > I think it would be interesting first to learn who on this distribution > prefers to provide lower-layer security for SIP with IPSec rather than TLS, > and then moreover whether those that do prefer IPSec would rather use > transport mode (host-by-host, integrated with SIP applications) or tunnel > mode (not integrated with SIP applications, using security gateways). I think the important question to ask here is how many people are implementing UDP UA's. > Just to be clear about a couple of things surrounding this proposed IPSec > profile: > > - Can we spell out a bit what we mean by HMAC-MD5-NULL? The string doesn't > appear in 2406, anyway. For example, is the NULL for authentication, or > encryption, or both? NULL encryption transform. RFC 2410 describes it. > - Will implementations supporting this profile by be compliant with the > minimum conformance requirements in rfc2406 section 5? Not to the letter of the law. The only encryption manadatory is DES and NULL; you can say that DES is forbidden by policy and optimized out of the code (many do, actually). Beyond that, you'd need SHA-1, though I frankly think that might have been overkill. > - This assumes pre-shared keys, and entails no key exchange capabilities > (i.e. IKE), right? Right. As in, you punt on key exchange. 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 daemon@optimus.ietf.org Mon Jan 28 19:22:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11853 for ; Mon, 28 Jan 2002 19:22:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA12624 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 19:22:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11505; Mon, 28 Jan 2002 18:55:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA11475 for ; Mon, 28 Jan 2002 18:55:34 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11496 for ; Mon, 28 Jan 2002 18:55:30 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0SNtVb24059; Mon, 28 Jan 2002 17:55:31 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 17:55:31 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE4C@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" Cc: sip@ietf.org Subject: RE: [Sip] TLS section Date: Mon, 28 Jan 2002 17:55:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org More below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, January 28, 2002 2:32 PM > To: Peterson, Jon > Cc: 'Michael Thomas'; sip@ietf.org > Subject: RE: [Sip] TLS section > > > Peterson, Jon writes: [snip] > > I find it confusing because it's not correct > in a pretty large way. That is, reading this > tells me that the authors (maybe you! :) are > conflating message integrity/encryption with > credentials. Addressing this point any further would be splitting hairs, and most likely wasting our time. We'll attempt to bulletproof this language a bit. > > Frankly, I'd give up any other distinction than the > two obvious ones: > > o IPsec allows use of UDP > o TLS currently has an API to access the > credentials, while IPsec requires that > API to be built. I agree those are important considerations, and I think they come across in the document. We'll attempt to prune around these points so as not to offend any delicate sensibilities. > > > > The security solutions section, 22.3.2, suggests a way that this > > transitivity might be used in a real-life deployment. Although it's > > distasteful to you, I think it jibes with the core needs of SIP. > > We all know how to ignore the transitive > problem. That's as simple as ignoring it. > The other problem with this paragraph is > that it implies there's some quantifiable difference > between TLS or IPsec here. There isn't; > neither can help you, nor will they impede your > memory cells from losing all knowledge of > the transitive trust problem. > SIP is predicated on trusting intermediaries that route sessions, it's true. If the fact that many elements may conspire to route a session is a bug, and not a feature, then perhaps your problem is with SIP itself. So I guess I agree that you have to 'ignore' it, or at least work around the fact that there are intermediaries. I also do agree that the passage illustrating transitivity with Alice and Bob does not represent a relationship that can only be instantiated by TLS - that just happened to land here because transitivity was mentioned. > > > Nothing addresses security for UDP and thus the > spec is incomplete. > > Today, SIP clients can use UDP without using IPSec, and that won't change if we make IPSec mandatory to implement. Now that UDP and TCP are both mandatory in UAs, clients have a choice - either use UDP, which has no recommended lower-layer security mechanism in the specification, or use TCP, which you can secure with TLS. I don't see how this is 'incomplete' just because a UA can choose to communicate in an insecure fashion. If all proxy servers support TCP and TLS, then it sounds to me like a client that supports TLS can always make a secure 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 daemon@optimus.ietf.org Mon Jan 28 19:25:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11913 for ; Mon, 28 Jan 2002 19:25:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA12715 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 19:25:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12283; Mon, 28 Jan 2002 19:07:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12178 for ; Mon, 28 Jan 2002 19:07:23 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11694 for ; Mon, 28 Jan 2002 19:07:21 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0T07Fb24338; Mon, 28 Jan 2002 18:07:15 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 18:07:15 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE4D@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" Cc: "'Rosen, Brian'" , sip@ietf.org Subject: RE: [Sip] TLS section Date: Mon, 28 Jan 2002 18:07:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org While I don't know what the IESG favors for security profiles, I have to say that a profile that requires no minimum algorithm for confidentiality and no key exchange mechanism doesn't exactly sound like a recipe for interoperability. While I understand your reluctance to require DES (the minimum encryption algorithm mandated by 2406), I would think you'd have to require something for encryption. Similarly, I would think there would have to be some story for key exchange. Or at least, in the absence of concrete mechanisms for these I'd think there would be a significant argument that the bis06 profile of TLS (for which we're specifying a more encompassing minimum ciphersuite) is more likely to be interoperable. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, January 28, 2002 3:39 PM > To: Peterson, Jon > Cc: 'Rosen, Brian'; 'Michael Thomas'; sip@ietf.org > Subject: RE: [Sip] TLS section > > > Peterson, Jon writes: > > Thanks Brian, I'm actually really interested in this topic as well. > > > > I think it would be interesting first to learn who on this > distribution > > prefers to provide lower-layer security for SIP with IPSec > rather than TLS, > > and then moreover whether those that do prefer IPSec would > rather use > > transport mode (host-by-host, integrated with SIP > applications) or tunnel > > mode (not integrated with SIP applications, using security > gateways). > > I think the important question to ask here is how > many people are implementing UDP UA's. > > > Just to be clear about a couple of things surrounding this > proposed IPSec > > profile: > > > > - Can we spell out a bit what we mean by HMAC-MD5-NULL? > The string doesn't > > appear in 2406, anyway. For example, is the NULL for > authentication, or > > encryption, or both? > > NULL encryption transform. RFC 2410 describes it. > > > - Will implementations supporting this profile by be > compliant with the > > minimum conformance requirements in rfc2406 section 5? > > Not to the letter of the law. The only encryption > manadatory is DES and NULL; you can say that DES > is forbidden by policy and optimized out of the > code (many do, actually). Beyond that, you'd need > SHA-1, though I frankly think that might have been > overkill. > > > - This assumes pre-shared keys, and entails no key > exchange capabilities > > (i.e. IKE), right? > > Right. As in, you punt on key exchange. > > 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 daemon@optimus.ietf.org Mon Jan 28 19:37:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12143 for ; Mon, 28 Jan 2002 19:37:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13471 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 19:37:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12603; Mon, 28 Jan 2002 19:21:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12539 for ; Mon, 28 Jan 2002 19:21:40 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11844 for ; Mon, 28 Jan 2002 19:21:33 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0T0L4L06516; Mon, 28 Jan 2002 16:21:04 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT65472; Mon, 28 Jan 2002 16:20:32 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA21137; Mon, 28 Jan 2002 16:21:02 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.60142.438496.110634@thomasm-u1.cisco.com> Date: Mon, 28 Jan 2002 16:21:02 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , "'Rosen, Brian'" , sip@ietf.org Subject: RE: [Sip] TLS section In-Reply-To: <70565611B164D511957A001083FCDD56CAAE4D@VA02> References: <70565611B164D511957A001083FCDD56CAAE4D@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > While I don't know what the IESG favors for security profiles, I have to say > that a profile that requires no minimum algorithm for confidentiality and no > key exchange mechanism doesn't exactly sound like a recipe for > interoperability. While I understand your reluctance to require DES (the > minimum encryption algorithm mandated by 2406), I would think you'd have to > require something for encryption. Not at all. Remember, the original IPsec only had AH. ESP and then ESP with NULL Encryption came much later. Lack of message integrity is at the root of almost every threat. Plus, lots of other protocols have minimum requirements for just message integrity. > Similarly, I would think there would have > to be some story for key exchange. I don't think SIP needs to boil the ocean here. We need a base level mechanism to make the transport of secured SIP messages. Picking one in fact complicates the matter by unnecessarily constraining the design space of what is really a system architecture issue. > Or at least, in the absence of concrete mechanisms for these I'd think there > would be a significant argument that the bis06 profile of TLS (for which > we're specifying a more encompassing minimum ciphersuite) is more likely to > be interoperable. I think SIP mainly needs to mind its own business. Picking winners and losers in the authentication game is *wildly* out of charter, IMO. 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 daemon@optimus.ietf.org Mon Jan 28 19:40:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12201 for ; Mon, 28 Jan 2002 19:40:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA13548 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 19:40:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12690; Mon, 28 Jan 2002 19:23:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12661 for ; Mon, 28 Jan 2002 19:23:54 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11873 for ; Mon, 28 Jan 2002 19:23:52 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0T0NII21052; Mon, 28 Jan 2002 16:23:18 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT65519; Mon, 28 Jan 2002 16:22:46 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA21140; Mon, 28 Jan 2002 16:23:16 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.60276.858845.659265@thomasm-u1.cisco.com> Date: Mon, 28 Jan 2002 16:23:16 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org In-Reply-To: <70565611B164D511957A001083FCDD56CAAE4C@VA02> References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sip] Bis-06 and Deprecating UDP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > Today, SIP clients can use UDP without using IPSec, and that won't change if > we make IPSec mandatory to implement. Now that UDP and TCP are both > mandatory in UAs, clients have a choice - either use UDP, which has no > recommended lower-layer security mechanism in the specification, or use TCP, > which you can secure with TLS. I don't see how this is 'incomplete' just > because a UA can choose to communicate in an insecure fashion. If all proxy > servers support TCP and TLS, then it sounds to me like a client that > supports TLS can always make a secure connection. It's incomplete because a perfectly valid transport mode -- UDP -- doesn't have a perfectly valid MUST IMPLEMENT security scheme. What you're saying is "if you want security, use TLS". That is not helpful for when you use UDP. Frankly, I think this debate would be much better served by talking about what the *real* implication is here: deprecating UDP. Are you and the rest of the authors ready to do that? Making UDP a poor relation to TCP has the same effect. So we either keep it as a valid option or deprecate it altogether. One or the other. This current wishy-washiness is the worst of all worlds. 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 daemon@optimus.ietf.org Mon Jan 28 20:08:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12541 for ; Mon, 28 Jan 2002 20:08:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA14873 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 20:08:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13442; Mon, 28 Jan 2002 19:36:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13413 for ; Mon, 28 Jan 2002 19:36:22 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12131 for ; Mon, 28 Jan 2002 19:36:20 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0T0VIb24865; Mon, 28 Jan 2002 18:31:19 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 18:31:18 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE4E@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" Cc: "'Rosen, Brian'" , sip@ietf.org Subject: RE: [Sip] TLS section Date: Mon, 28 Jan 2002 18:31:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Yet still more below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, January 28, 2002 4:21 PM > To: Peterson, Jon > Cc: 'Michael Thomas'; 'Rosen, Brian'; sip@ietf.org > Subject: RE: [Sip] TLS section > > > Peterson, Jon writes: > > While I don't know what the IESG favors for security > profiles, I have to say > > that a profile that requires no minimum algorithm for > confidentiality and no > > key exchange mechanism doesn't exactly sound like a recipe for > > interoperability. While I understand your reluctance to > require DES (the > > minimum encryption algorithm mandated by 2406), I would > think you'd have to > > require something for encryption. > > Not at all. Remember, the original IPsec only had > AH. ESP and then ESP with NULL Encryption came > much later. Lack of message integrity is at the > root of almost every threat. Plus, lots of other > protocols have minimum requirements for just > message integrity. Known threat models against SIP motivate a need for confidentiality, regardless of what IPSec is minimally capable of supporting, or what other protocols require. > > > Similarly, I would think there would have > > to be some story for key exchange. > > I don't think SIP needs to boil the ocean here. We > need a base level mechanism to make the transport > of secured SIP messages. Picking one in fact > complicates the matter by unnecessarily > constraining the design space of what is really a > system architecture issue. The idea isn't to pick one and say you can't use any alternatives - just to pick one so that SIP entities will be interoperable; then system architects can use others as they like to streamline deployments, but without threatening interoperability. Again, TLS has no need to boil any oceans over this. You may not favor its key exchange mechanisms, but it does have mechanisms that all endpoints will support. > > > Or at least, in the absence of concrete mechanisms for > these I'd think there > > would be a significant argument that the bis06 profile of > TLS (for which > > we're specifying a more encompassing minimum ciphersuite) > is more likely to > > be interoperable. > > I think SIP mainly needs to mind its own business. > Picking winners and losers in the authentication > game is *wildly* out of charter, IMO. I thought that we were charged by the IESG to identify the tools could be used to secure our protocol - not to put out a protocol and assume somebody else in the IETF, or worse various vendors/service providers, must determine how to apply security to it before it can be deployed. I understand that we need to choose something, not exclusively but minimally, that goes into our Security Considerations section. Again, this is perhaps something for the IESG to clarify. > > 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 daemon@optimus.ietf.org Mon Jan 28 20:14:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12619 for ; Mon, 28 Jan 2002 20:14:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA14960 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 20:14:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13380; Mon, 28 Jan 2002 19:34:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13349 for ; Mon, 28 Jan 2002 19:34:49 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12123 for ; Mon, 28 Jan 2002 19:34:47 -0500 (EST) Received: from dingdong.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0T0YJc16044; Mon, 28 Jan 2002 19:34:20 -0500 (EST) Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAQ00924; Mon, 28 Jan 2002 19:34:04 -0500 (EST) Message-ID: <3C55EDFC.7B0B1C49@cisco.com> Date: Mon, 28 Jan 2002 19:34:04 -0500 From: Kevin Lingle X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: taylor@nortelnetworks.com CC: sip@ietf.org, Jean-Francois Mule , Dave Walker , Joon Maeng References: <28560036253BD41191A10000F8BCBD1105848226@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Review of draft-ietf-sip-mib-03.txt Part 2 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit tom, below please find our responses to this second round of comments. sorry for the delay. if you are satisfied with the answers, we'd like to produce a new revision of the draft (-04) and wish you to give it one final look. we are seeking your final approval so we can consider sip wg last call on this draft complete and proceed with the next step: rfc-editor. thanks for your time and insight in reviewing this draft! > Tom-PT Taylor wrote: > > Further comments > ================ > SIP-COMMON-MIB (cont'd) > > A further remark on sipInviteTimeout: in principle we need an > application-level timeout value for each method, not just INVITE. We > might possibly get away with one for initial INVITE and one for all > other requests. Clearly the expected turnaround for a REGISTER will > be different from that for a PRACK, but both of them should finish in > a few seconds at most rather than the minutes an initial INVITE could > take. I will again question whether application-level timers belong > in SIP-COMMON-MIB or in SIP-UA-MIB. we removed sipInviteTimeout and created sipCommonCfgExpiresMethodTable to deal with the Expires header values more generally with app-level expiration timer. > > sipMethodStatsEntry: INFO method should be treated like all other > extensions, rather than appear explicitly in this table. we made a conscious decision to include INFO related object back in rev -02 of the draft. INFO was formalized by RFC 2976 in 10/2000, so we felt comfortable including. therefore, we've retained INFO related object in the draft mibs. > > sipSummaryTotalTransactions: description should indicate what a > transaction stateless proxy does with this counter (probably leaves it > at 0). ok. we added... "For a transaction stateless proxy, this counter is always 0." to the description. > > sipStatsInfoIns, Outs: shouldn't be given special treatment -- belong > in the sipStatsExtMethodTable with all the other method extensions. see the answer regarding sipMethodStatsEntry above. > > SipStatusCodesEntry: should "other" class entries be defined, for > status codes 700 and up? ok. we added two new object to the sipStatusCodesTable: sipStatsOtherClassesIns sipStatsOtherClassesOuts > > sipStatsRedirClassIns, Outs: 3xx responses don't necessarily come from > Redirect Servers -- UAs could be set up to forward calls, for > instance. Hence the phrase "taken by a Redirect Server" in the > description is inappropriate. ok. we removed the phrase. > > sipStatsServerFailClassIns, Outs: final sentence of description > defines SIP protocol behaviour, not SNMP Agent behaviour, hence should > be omitted. ok. we removed the final sentence from the descriptions. > > sipStatsGlobalFailClassIns, Outs: ditto ok. we removed the final sentence from the descriptions. > > sipStatsExtMethodStatus: description is a bit sparse. Would something > more along the lines of the description for sipCommonStatusCodeStatus > not be desirable here too? yes, we fleshed out the description with the same text you reference. > > sipStatusCodeNotifTo, From, CallId, CSeq: do the reported values > include the header keywords themselves, or only the part following the > colon? (e.g.) "From:xx..x" vs. "xx..x" ok. we added to the descriptions saying "header name" is part of the value and examples were given. > > sipCurrentTransTable: need something be said about transaction > stateless proxies? ok. we added words that this table and sipTransactionTable do not apply to transaction stateless proxies. > > sipCurrentTransEntry: typo in description -- should be "entity's" > rather than "entities'". fixed typo. > > SipTransactionEntry: need an object identifying the method which > initiated the transaction. ok. we added a new object ... sipTransMethod (SnmpAdminString)... to the table. > > sipTransTo, From, CallId, CSeq: do the reported values include the > header keywords themselves, or only the part following the colon? > (e.g.) "From:xx..x" vs. "xx..x" ok. we added to the descriptions saying "header name" is part of the value and examples were given. > > sipTransState: most of these states apply only to INVITE transactions, > and some of them (null, completed, confirmed) do not apply to > transactions currently in process. I would suggest instead capturing > the latest activity in the transaction. This has two parts: direction > (received/sent) and status code value or request (the latter being > either the initiating request or ACK). we attempted to align the states with bis05, but it proved difficult to reconcile the differences between rfc2543 and bis05. some states match for INVITES while not for other methods and vice versa. therefore, we did not change any state values in the mib. we adding text to the description noting that not all values of the object are applicable to all transaction types. is that ok, tom? we did add one new string object to deal with the "latest activity" issue you raised. we gave examples of what that string value might look like for both direction and requests vs. responses. (see sipTransActivityInfo object in next revision) > > sipTransExpiry: behaviour will be affected by the outcome of my > initial remark on sipInviteTimeout. <<< J-F, please check... this is suppose to match up w/ or be in line with the answer to the first comment>>> > > sipTransCallingPartyContentType, sipTransCalledPartyContentType: nice > try, but it doesn't work. Content type varies from message to message > within a transaction. Perhaps these objects could record the > aggregation of content types over all messages so far passed in the > transaction -- that would reflect your intent. not sure we understood your suggestion, but it sounded like too much information and too complicated, so we punted ;)... removed the objects from the mib. > > > SipCommonStatsRetryEntry: as with sipMethodStatsEntry, the INFO method > should be treated like all other extensions, rather than appear > explicitly in this table. same answer as given above wrt why we included and wish to retain INFO related objects. > > sipOtherStatsEntry: typo in description -- should be "entity's" rather > than "entities'". fixed typo. > > sipNotifApplIndex: doesn't point to the actual status code being > monitored. Shouldn't it be the same structure as the index of > sipCommonStatusCodeTable? we had already discovered this. we fixed it by including in/out counter objects from sipCommonStatusCodeTable. the applIndex will be implicitly conveyed by these objects' OIDs. > > SIP-UA-MIB > ========== > > General comment on configuration: should there be a requirement to > populate the SIP-COMMON-MIB data for each entity before populating > this MIB? How is this expressed? we don't believe we need (should) provide this level of detailed guidance in the MIB. it ventures too far into the realm of implementation. > > sipUAMIBNotifs is empty. it was a placeholder for the future. not notifs were identified so we've removed it. > > Where is the definition of sipUAStats?? another placeholder. none were ever identified. we've removed it. > > sipUACfgSipServerEntry: should say that applIndex for each entity > instance has the same value as used for that instance in the tables of > SIP-COMMON-MIB. ok. we added... "The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." to the description. > > Might it be desirable to configure the UA's Contact address? providing this turned out to be more complicated than initially thought. we first thought the contact address could only be present in a limited set of request and responses. it turns out to be a larger set than expected. moreover, we don't think people will really want to use the mib to configure this because the contact field is very user dependent and is likely to be better controlled in the context of a application on top of sip. that can take us away from pure sip protocol mgmt - which should be the focus of these mibs. therefore, we've not done anything in the mibs regarding this comment. > > SIP-SERVER-MIB > ============== > > General comment on configuration: should there be a requirement to > populate the SIP-COMMON-MIB data for each entity before populating > this MIB? How is this expressed? again, we don't believe we need (should) provide this level of detailed guidance in the MIB. it ventures too far into the realm of implementation. > > sipServerMIB: description has definitions of the different server > types. Would it be safer to refer to the RFC instead? In any event, > a Proxy does not initiate requests (as indicated in the definition of > a Redirect Server). It does propagate them. it's useful to have explicit text in the mib for the implementor. we wish to leave it as-is. except we have removed the statement in redirect server section. > > sipServerCfgEntry: should say that applIndex for each instance has the > same value as in SIP-COMMON-MIB. Question: should there be a > RowStatus object? Can values be changed on the fly? part one: ok. added... "The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." to the description. part two: we do not wish to add a RowStatus object. we're not sure of a requirement to create/delete server entities in a system. wrt "changing on the fly"... it would be implementation specific. > > SipProxyCfgEntry: should there be a RowStatus object? we do not wish to add a RowStatus object. we're not sure of a requirement to create/delete server entities in a system. > > SipRegCfgEntry: ditto ditto ;) > > sipContactPreference: typed as an OCTET STRING. Couldn't that be an > IA5String, or is that not allowed in SNMP? we changed the object to be a SnmpAdminString. please let us know if you have and concerns/doubts about how we've addressed your questions/issues. once we've pulled together the rev -04 of the draft, we'll pass it along to you for a final review. thank you, tom! SIP MIB Team Kevin Lingle, Cisco Joon Maeng, ipDialog David Walker, SS8 Networks Jean-Francios Mule > > > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 20:14:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12636 for ; Mon, 28 Jan 2002 20:14:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA14992 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 20:14:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13914; Mon, 28 Jan 2002 19:53:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13883 for ; Mon, 28 Jan 2002 19:53:45 -0500 (EST) Received: from hotmail.com (f103.law15.hotmail.com [64.4.23.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12347 for ; Mon, 28 Jan 2002 19:53:42 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 28 Jan 2002 16:53:14 -0800 Received: from 63.113.13.210 by lw15fd.law15.hotmail.msn.com with HTTP; Tue, 29 Jan 2002 00:53:14 GMT X-Originating-IP: [63.113.13.210] From: "George Smith" To: jdrosen@dynamicsoft.com, deleow@telefonica.com.ar Cc: sip@ietf.org Subject: Re: [Sip] Re: draft-rosenberg-sip-app-components-01 Date: Mon, 28 Jan 2002 16:53:14 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Jan 2002 00:53:14.0332 (UTC) FILETIME=[54EDE1C0:01C1A85F] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Please do rev it so it stays alive. >From: Jonathan Rosenberg >To: De Leo Walter >CC: "'sip@ietf.org'" >Subject: [Sip] Re: draft-rosenberg-sip-app-components-01 >Date: Sun, 27 Jan 2002 13:28:46 -0500 > > > >De Leo Walter wrote: > > > > As this draft has expired I'd like to know if there is a new version in > > the > > oven or it has been renamed or let die. > >Although there appears to be much interest in this work, it is not one >the charter of sip or sipping at this time. I may rev it to keep it >alive for reference, but chartered items take higher precedence for me >right now. > >-Jonathan R. > >-- >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 20:15:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12653 for ; Mon, 28 Jan 2002 20:15:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA15009 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 20:15:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13842; Mon, 28 Jan 2002 19:50:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13811 for ; Mon, 28 Jan 2002 19:50:43 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12326 for ; Mon, 28 Jan 2002 19:50:38 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA19141; Mon, 28 Jan 2002 19:50:19 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0T0oGJ1016957; Mon, 28 Jan 2002 19:50:17 -0500 (EST) Message-ID: <3C55F1C8.D4A0C591@cs.columbia.edu> Date: Mon, 28 Jan 2002 19:50:16 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Michael Thomas'" , sip@ietf.org Subject: Re: [Sip] TLS section References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > mandatory in UAs, clients have a choice - either use UDP, which has no > recommended lower-layer security mechanism in the specification, or use TCP, The primary concern mentioned is integrity. Proxy authentication addresses this about as well as IPsec without key exchange (modulo the need to fix the Digest problems, but they need to be fixed regardless of the choice of lower-layer crypto). -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 20:21:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12732 for ; Mon, 28 Jan 2002 20:21:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA15295 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 20:21:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14281; Mon, 28 Jan 2002 20:00:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14238 for ; Mon, 28 Jan 2002 20:00:17 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12449 for ; Mon, 28 Jan 2002 20:00:15 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA19802; Mon, 28 Jan 2002 19:59:57 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0T0xvJ1017340; Mon, 28 Jan 2002 19:59:57 -0500 (EST) Message-ID: <3C55F40D.75F1C3D@cs.columbia.edu> Date: Mon, 28 Jan 2002 19:59:57 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] TLS section References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> <3C55F1C8.D4A0C591@cs.columbia.edu> <15445.62127.110684.7938@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Henning G. Schulzrinne writes: > > The primary concern mentioned is integrity. Proxy authentication > > addresses this about as well as IPsec without key exchange > > You can't be serious. Thanks for your helpful response. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 20:21:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12754 for ; Mon, 28 Jan 2002 20:21:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA15335 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 20:21:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13959; Mon, 28 Jan 2002 19:55:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA13931 for ; Mon, 28 Jan 2002 19:55:15 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12362 for ; Mon, 28 Jan 2002 19:55:12 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0T0s8I10849; Mon, 28 Jan 2002 16:54:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT66439; Mon, 28 Jan 2002 16:53:37 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA21144; Mon, 28 Jan 2002 16:54:07 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.62127.110684.7938@thomasm-u1.cisco.com> Date: Mon, 28 Jan 2002 16:54:07 -0800 (PST) To: "Henning G. Schulzrinne" Cc: "Peterson, Jon" , "'Michael Thomas'" , sip@ietf.org Subject: Re: [Sip] TLS section In-Reply-To: <3C55F1C8.D4A0C591@cs.columbia.edu> References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> <3C55F1C8.D4A0C591@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning G. Schulzrinne writes: > The primary concern mentioned is integrity. Proxy authentication > addresses this about as well as IPsec without key exchange You can't be serious. 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 daemon@optimus.ietf.org Mon Jan 28 20:22:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12786 for ; Mon, 28 Jan 2002 20:22:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA15451 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 20:23:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14518; Mon, 28 Jan 2002 20:00:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14486 for ; Mon, 28 Jan 2002 20:00:49 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12465 for ; Mon, 28 Jan 2002 20:00:47 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0T10EI15107; Mon, 28 Jan 2002 17:00:15 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT66621; Mon, 28 Jan 2002 16:59:37 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA21147; Mon, 28 Jan 2002 17:00:07 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.62487.288418.585929@thomasm-u1.cisco.com> Date: Mon, 28 Jan 2002 17:00:07 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , "'Rosen, Brian'" , sip@ietf.org Subject: RE: [Sip] TLS section In-Reply-To: <70565611B164D511957A001083FCDD56CAAE4E@VA02> References: <70565611B164D511957A001083FCDD56CAAE4E@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > Known threat models against SIP motivate a need for confidentiality, > regardless of what IPSec is minimally capable of supporting, or what other > protocols require. I don't actually care a lot about this. That is, picking an encryption algorithm would be acceptible to me too. I'm just trying to point out that a minimum which didn't encrypt would be a lot better than nothing, and would be acceptible as a minimum must implement to me. > > > Similarly, I would think there would have > > > to be some story for key exchange. > > > > I don't think SIP needs to boil the ocean here. We > > need a base level mechanism to make the transport > > of secured SIP messages. Picking one in fact > > complicates the matter by unnecessarily > > constraining the design space of what is really a > > system architecture issue. > > The idea isn't to pick one and say you can't use any alternatives - just to > pick one so that SIP entities will be interoperable; then system architects > can use others as they like to streamline deployments, but without > threatening interoperability. Specifying one will not get you any closer to interoperability if you want meaningful access control. You run into the infamous "global PKI" as the next on the agenda. I think steering well clear of this is by far the most prudent. > > I think SIP mainly needs to mind its own business. > > Picking winners and losers in the authentication > > game is *wildly* out of charter, IMO. > > I thought that we were charged by the IESG to identify the tools could be > used to secure our protocol - not to put out a protocol and assume somebody > else in the IETF, or worse various vendors/service providers, must determine > how to apply security to it before it can be deployed. The Security Area doesn't even talk with a single voice in this area. Why should SIP? > I understand that we need to choose something, not exclusively but > minimally, that goes into our Security Considerations section. Again, this > is perhaps something for the IESG to clarify. A MUST IMPLEMENT implies that it is required for interoperability. As I said before, that is a false illusion; you will be stopped cold by the mythical global PKI. This cannot be settled in the IETF except to provide the tools to let reality decide. 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 daemon@optimus.ietf.org Mon Jan 28 20:24:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12831 for ; Mon, 28 Jan 2002 20:24:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA15530 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 20:24:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14566; Mon, 28 Jan 2002 20:01:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14539 for ; Mon, 28 Jan 2002 20:01:02 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12468 for ; Mon, 28 Jan 2002 20:00:59 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA19602; Mon, 28 Jan 2002 19:56:49 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0T0umJ1017191; Mon, 28 Jan 2002 19:56:48 -0500 (EST) Message-ID: <3C55F350.A3A88ACF@cs.columbia.edu> Date: Mon, 28 Jan 2002 19:56:48 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: "James M. Polk" CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu Subject: Re: [Sip] bis-06 now available! References: <4.1.20020128161005.02da2788@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Very strange. The section should have / instead of |, too. I suspect that CVS acted up on us. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Mon Jan 28 20:25:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12882 for ; Mon, 28 Jan 2002 20:25:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA15585 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 20:25:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14727; Mon, 28 Jan 2002 20:02:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14696 for ; Mon, 28 Jan 2002 20:02:30 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12497 for ; Mon, 28 Jan 2002 20:02:27 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0T12Mb25585; Mon, 28 Jan 2002 19:02:22 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 19:02:22 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE50@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" Cc: sip@ietf.org Date: Mon, 28 Jan 2002 19:02:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Bis-06 and Deprecating UDP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org TCP doesn't have a MUST implement security scheme either - TLS is merely strongly RECOMMENDED, you'll note. I don't think the current text of bis amounts to the deprecation of UDP. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, January 28, 2002 4:23 PM > To: Peterson, Jon > Cc: 'Michael Thomas'; sip@ietf.org > Subject: Bis-06 and Deprecating UDP > > > Peterson, Jon writes: > > Today, SIP clients can use UDP without using IPSec, and > that won't change if > > we make IPSec mandatory to implement. Now that UDP and TCP are both > > mandatory in UAs, clients have a choice - either use UDP, > which has no > > recommended lower-layer security mechanism in the > specification, or use TCP, > > which you can secure with TLS. I don't see how this is > 'incomplete' just > > because a UA can choose to communicate in an insecure > fashion. If all proxy > > servers support TCP and TLS, then it sounds to me like a > client that > > supports TLS can always make a secure connection. > > It's incomplete because a perfectly valid transport > mode -- UDP -- doesn't have a perfectly valid MUST > IMPLEMENT security scheme. What you're saying is > "if you want security, use TLS". That is not > helpful for when you use UDP. > > Frankly, I think this debate would be much better > served by talking about what the *real* > implication is here: deprecating UDP. Are you > and the rest of the authors ready to do that? > Making UDP a poor relation to TCP has the same > effect. So we either keep it as a valid option > or deprecate it altogether. One or the other. > This current wishy-washiness is the worst of > all worlds. > > 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 daemon@optimus.ietf.org Mon Jan 28 20:44:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13367 for ; Mon, 28 Jan 2002 20:44:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA16643 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 20:44:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15202; Mon, 28 Jan 2002 20:16:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA15084 for ; Mon, 28 Jan 2002 20:16:10 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12680 for ; Mon, 28 Jan 2002 20:16:07 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0T1G5b03843; Mon, 28 Jan 2002 20:16:05 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 19:16:05 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE51@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" Cc: "'Rosen, Brian'" , sip@ietf.org Subject: RE: [Sip] TLS section Date: Mon, 28 Jan 2002 19:16:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Well, I think this thread must be getting close to a conclusion. To sum up what I read below, global PKI is a myth and the IESG is balkanized, and the standards process isn't really meaningful anyway - "reality" must decide. Even if all of this is true, some of us believe, irrationally perhaps, that getting this document past the IESG to RFC is tractable, and moreover worth doing. In any event, I do think any proposed profile for IPSec, if we end up arriving at one, should suggest a minimum encryption algorithm. You're probably right that one that didn't encrypt would be better than nothing, but I think it would fall short of our requirements. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, January 28, 2002 5:00 PM > To: Peterson, Jon > Cc: 'Michael Thomas'; 'Rosen, Brian'; sip@ietf.org > Subject: RE: [Sip] TLS section > > > Peterson, Jon writes: > > Known threat models against SIP motivate a need for > confidentiality, > > regardless of what IPSec is minimally capable of > supporting, or what other > > protocols require. > > I don't actually care a lot about this. That is, > picking an encryption algorithm would be acceptible > to me too. I'm just trying to point out that a > minimum which didn't encrypt would be a lot better > than nothing, and would be acceptible as a minimum > must implement to me. > > > > > Similarly, I would think there would have > > > > to be some story for key exchange. > > > > > > I don't think SIP needs to boil the ocean here. We > > > need a base level mechanism to make the transport > > > of secured SIP messages. Picking one in fact > > > complicates the matter by unnecessarily > > > constraining the design space of what is really a > > > system architecture issue. > > > > The idea isn't to pick one and say you can't use any > alternatives - just to > > pick one so that SIP entities will be interoperable; then > system architects > > can use others as they like to streamline deployments, but without > > threatening interoperability. > > Specifying one will not get you any closer > to interoperability if you want meaningful > access control. You run into the infamous > "global PKI" as the next on the agenda. I > think steering well clear of this is by far > the most prudent. > > > > I think SIP mainly needs to mind its own business. > > > Picking winners and losers in the authentication > > > game is *wildly* out of charter, IMO. > > > > I thought that we were charged by the IESG to identify the > tools could be > > used to secure our protocol - not to put out a protocol > and assume somebody > > else in the IETF, or worse various vendors/service > providers, must determine > > how to apply security to it before it can be deployed. > > The Security Area doesn't even talk with a > single voice in this area. Why should SIP? > > > I understand that we need to choose something, not exclusively but > > minimally, that goes into our Security Considerations > section. Again, this > > is perhaps something for the IESG to clarify. > > A MUST IMPLEMENT implies that it is required > for interoperability. As I said before, that is > a false illusion; you will be stopped cold by > the mythical global PKI. This cannot be > settled in the IETF except to provide the tools > to let reality decide. > > 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 daemon@optimus.ietf.org Mon Jan 28 21:06:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13550 for ; Mon, 28 Jan 2002 21:05:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA17503 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 21:05:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16758; Mon, 28 Jan 2002 20:47:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16730 for ; Mon, 28 Jan 2002 20:47:36 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13411 for ; Mon, 28 Jan 2002 20:47:33 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0T1kXd13607; Mon, 28 Jan 2002 17:46:33 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT67877; Mon, 28 Jan 2002 17:46:02 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA21157; Mon, 28 Jan 2002 17:46:33 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15445.65272.912480.573413@thomasm-u1.cisco.com> Date: Mon, 28 Jan 2002 17:46:32 -0800 (PST) To: "Henning G. Schulzrinne" Cc: Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] TLS section In-Reply-To: <3C55F40D.75F1C3D@cs.columbia.edu> References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> <3C55F1C8.D4A0C591@cs.columbia.edu> <15445.62127.110684.7938@thomasm-u1.cisco.com> <3C55F40D.75F1C3D@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning G. Schulzrinne writes: > Michael Thomas wrote: > > > > Henning G. Schulzrinne writes: > > > The primary concern mentioned is integrity. Proxy authentication > > > addresses this about as well as IPsec without key exchange > > > > You can't be serious. > > Thanks for your helpful response. Anybody who claims that a challenge/response protocol -- which does not purport to protect every message, prevent replays, etc, etc -- is either sadly misinformed, or not serious. Take your choice. 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 daemon@optimus.ietf.org Mon Jan 28 22:41:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16479 for ; Mon, 28 Jan 2002 22:41:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA20973 for sip-archive@odin.ietf.org; Mon, 28 Jan 2002 22:41:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19694; Mon, 28 Jan 2002 22:10:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19597 for ; Mon, 28 Jan 2002 22:10:11 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15105 for ; Mon, 28 Jan 2002 22:10:07 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0T39J720596; Mon, 28 Jan 2002 22:09:19 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0T39Fr12809; Mon, 28 Jan 2002 22:09:16 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 22:09:17 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102AF2F@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Kevin Lingle'" Cc: sip@ietf.org, Jean-Francois Mule , Dave Walker , Joon Maeng Date: Mon, 28 Jan 2002 22:09:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A872.58ABB270" Subject: [Sip] RE: Review of draft-ietf-sip-mib-03.txt Part 2 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A872.58ABB270 Content-Type: text/plain; charset="ISO-8859-1" I'm happy with everything. -----Original Message----- From: Kevin Lingle [mailto:klingle@cisco.com] Sent: Monday, January 28, 2002 7:34 PM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: sip@ietf.org; Jean-Francois Mule; Dave Walker; Joon Maeng Subject: Re: Review of draft-ietf-sip-mib-03.txt Part 2 tom, below please find our responses to this second round of comments. sorry for the delay. if you are satisfied with the answers, we'd like to produce a new revision of the draft (-04) and wish you to give it one final look. we are seeking your final approval so we can consider sip wg last call on this draft complete and proceed with the next step: rfc-editor. thanks for your time and insight in reviewing this draft! > Tom-PT Taylor wrote: > > Further comments > ================ > SIP-COMMON-MIB (cont'd) > > A further remark on sipInviteTimeout: in principle we need an > application-level timeout value for each method, not just INVITE. We > might possibly get away with one for initial INVITE and one for all > other requests. Clearly the expected turnaround for a REGISTER will > be different from that for a PRACK, but both of them should finish in > a few seconds at most rather than the minutes an initial INVITE could > take. I will again question whether application-level timers belong > in SIP-COMMON-MIB or in SIP-UA-MIB. we removed sipInviteTimeout and created sipCommonCfgExpiresMethodTable to deal with the Expires header values more generally with app-level expiration timer. > > sipMethodStatsEntry: INFO method should be treated like all other > extensions, rather than appear explicitly in this table. we made a conscious decision to include INFO related object back in rev -02 of the draft. INFO was formalized by RFC 2976 in 10/2000, so we felt comfortable including. therefore, we've retained INFO related object in the draft mibs. > > sipSummaryTotalTransactions: description should indicate what a > transaction stateless proxy does with this counter (probably leaves it > at 0). ok. we added... "For a transaction stateless proxy, this counter is always 0." to the description. > > sipStatsInfoIns, Outs: shouldn't be given special treatment -- belong > in the sipStatsExtMethodTable with all the other method extensions. see the answer regarding sipMethodStatsEntry above. > > SipStatusCodesEntry: should "other" class entries be defined, for > status codes 700 and up? ok. we added two new object to the sipStatusCodesTable: sipStatsOtherClassesIns sipStatsOtherClassesOuts > > sipStatsRedirClassIns, Outs: 3xx responses don't necessarily come from > Redirect Servers -- UAs could be set up to forward calls, for > instance. Hence the phrase "taken by a Redirect Server" in the > description is inappropriate. ok. we removed the phrase. > > sipStatsServerFailClassIns, Outs: final sentence of description > defines SIP protocol behaviour, not SNMP Agent behaviour, hence should > be omitted. ok. we removed the final sentence from the descriptions. > > sipStatsGlobalFailClassIns, Outs: ditto ok. we removed the final sentence from the descriptions. > > sipStatsExtMethodStatus: description is a bit sparse. Would something > more along the lines of the description for sipCommonStatusCodeStatus > not be desirable here too? yes, we fleshed out the description with the same text you reference. > > sipStatusCodeNotifTo, From, CallId, CSeq: do the reported values > include the header keywords themselves, or only the part following the > colon? (e.g.) "From:xx..x" vs. "xx..x" ok. we added to the descriptions saying "header name" is part of the value and examples were given. > > sipCurrentTransTable: need something be said about transaction > stateless proxies? ok. we added words that this table and sipTransactionTable do not apply to transaction stateless proxies. > > sipCurrentTransEntry: typo in description -- should be "entity's" > rather than "entities'". fixed typo. > > SipTransactionEntry: need an object identifying the method which > initiated the transaction. ok. we added a new object ... sipTransMethod (SnmpAdminString)... to the table. > > sipTransTo, From, CallId, CSeq: do the reported values include the > header keywords themselves, or only the part following the colon? > (e.g.) "From:xx..x" vs. "xx..x" ok. we added to the descriptions saying "header name" is part of the value and examples were given. > > sipTransState: most of these states apply only to INVITE transactions, > and some of them (null, completed, confirmed) do not apply to > transactions currently in process. I would suggest instead capturing > the latest activity in the transaction. This has two parts: direction > (received/sent) and status code value or request (the latter being > either the initiating request or ACK). we attempted to align the states with bis05, but it proved difficult to reconcile the differences between rfc2543 and bis05. some states match for INVITES while not for other methods and vice versa. therefore, we did not change any state values in the mib. we adding text to the description noting that not all values of the object are applicable to all transaction types. is that ok, tom? we did add one new string object to deal with the "latest activity" issue you raised. we gave examples of what that string value might look like for both direction and requests vs. responses. (see sipTransActivityInfo object in next revision) > > sipTransExpiry: behaviour will be affected by the outcome of my > initial remark on sipInviteTimeout. <<< J-F, please check... this is suppose to match up w/ or be in line with the answer to the first comment>>> > > sipTransCallingPartyContentType, sipTransCalledPartyContentType: nice > try, but it doesn't work. Content type varies from message to message > within a transaction. Perhaps these objects could record the > aggregation of content types over all messages so far passed in the > transaction -- that would reflect your intent. not sure we understood your suggestion, but it sounded like too much information and too complicated, so we punted ;)... removed the objects from the mib. > > > SipCommonStatsRetryEntry: as with sipMethodStatsEntry, the INFO method > should be treated like all other extensions, rather than appear > explicitly in this table. same answer as given above wrt why we included and wish to retain INFO related objects. > > sipOtherStatsEntry: typo in description -- should be "entity's" rather > than "entities'". fixed typo. > > sipNotifApplIndex: doesn't point to the actual status code being > monitored. Shouldn't it be the same structure as the index of > sipCommonStatusCodeTable? we had already discovered this. we fixed it by including in/out counter objects from sipCommonStatusCodeTable. the applIndex will be implicitly conveyed by these objects' OIDs. > > SIP-UA-MIB > ========== > > General comment on configuration: should there be a requirement to > populate the SIP-COMMON-MIB data for each entity before populating > this MIB? How is this expressed? we don't believe we need (should) provide this level of detailed guidance in the MIB. it ventures too far into the realm of implementation. > > sipUAMIBNotifs is empty. it was a placeholder for the future. not notifs were identified so we've removed it. > > Where is the definition of sipUAStats?? another placeholder. none were ever identified. we've removed it. > > sipUACfgSipServerEntry: should say that applIndex for each entity > instance has the same value as used for that instance in the tables of > SIP-COMMON-MIB. ok. we added... "The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." to the description. > > Might it be desirable to configure the UA's Contact address? providing this turned out to be more complicated than initially thought. we first thought the contact address could only be present in a limited set of request and responses. it turns out to be a larger set than expected. moreover, we don't think people will really want to use the mib to configure this because the contact field is very user dependent and is likely to be better controlled in the context of a application on top of sip. that can take us away from pure sip protocol mgmt - which should be the focus of these mibs. therefore, we've not done anything in the mibs regarding this comment. > > SIP-SERVER-MIB > ============== > > General comment on configuration: should there be a requirement to > populate the SIP-COMMON-MIB data for each entity before populating > this MIB? How is this expressed? again, we don't believe we need (should) provide this level of detailed guidance in the MIB. it ventures too far into the realm of implementation. > > sipServerMIB: description has definitions of the different server > types. Would it be safer to refer to the RFC instead? In any event, > a Proxy does not initiate requests (as indicated in the definition of > a Redirect Server). It does propagate them. it's useful to have explicit text in the mib for the implementor. we wish to leave it as-is. except we have removed the statement in redirect server section. > > sipServerCfgEntry: should say that applIndex for each instance has the > same value as in SIP-COMMON-MIB. Question: should there be a > RowStatus object? Can values be changed on the fly? part one: ok. added... "The same value of applIndex used in the corresponding SIP-COMMON-MIB is used here." to the description. part two: we do not wish to add a RowStatus object. we're not sure of a requirement to create/delete server entities in a system. wrt "changing on the fly"... it would be implementation specific. > > SipProxyCfgEntry: should there be a RowStatus object? we do not wish to add a RowStatus object. we're not sure of a requirement to create/delete server entities in a system. > > SipRegCfgEntry: ditto ditto ;) > > sipContactPreference: typed as an OCTET STRING. Couldn't that be an > IA5String, or is that not allowed in SNMP? we changed the object to be a SnmpAdminString. please let us know if you have and concerns/doubts about how we've addressed your questions/issues. once we've pulled together the rev -04 of the draft, we'll pass it along to you for a final review. thank you, tom! SIP MIB Team Kevin Lingle, Cisco Joon Maeng, ipDialog David Walker, SS8 Networks Jean-Francios Mule > > > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Kevin R. Lingle 919.392.2029 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/ Sometimes I think I understand everything, then I regain consciousness. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ------_=_NextPart_001_01C1A872.58ABB270 Content-Type: text/html; charset="ISO-8859-1" RE: Review of draft-ietf-sip-mib-03.txt Part 2

I'm happy with everything.

-----Original Message-----
From: Kevin Lingle [mailto:klingle@cisco.com]
Sent: Monday, January 28, 2002 7:34 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: sip@ietf.org; Jean-Francois Mule; Dave Walker; Joon Maeng
Subject: Re: Review of draft-ietf-sip-mib-03.txt Part 2


tom,

below please find our responses to this second round of
comments.  sorry for the delay.

if you are satisfied with the answers, we'd like to produce
a new revision of the draft (-04) and wish you to give it
one final look.  we are seeking your final approval so we
can consider sip wg last call on this draft complete and
proceed with the next step: rfc-editor.

thanks for your time and insight in reviewing this draft!

> Tom-PT Taylor wrote:
>
> Further comments
> ================
> SIP-COMMON-MIB (cont'd)
>
> A further remark on sipInviteTimeout: in principle we need an
> application-level timeout value for each method, not just INVITE.  We
> might possibly get away with one for initial INVITE and one for all
> other requests.  Clearly the expected turnaround for a REGISTER will
> be different from that for a PRACK, but both of them should finish in
> a few seconds at most rather than the minutes an initial INVITE could
> take.  I will again question whether application-level timers belong
> in SIP-COMMON-MIB or in SIP-UA-MIB.

we removed sipInviteTimeout and created sipCommonCfgExpiresMethodTable
to deal with the Expires header values more generally with app-level
expiration timer.


>
> sipMethodStatsEntry: INFO method should be treated like all other
> extensions, rather than appear explicitly in this table.

we made a conscious decision to include INFO related object back in
rev -02 of the draft.  INFO was formalized by RFC 2976 in 10/2000,
so we felt comfortable including.  therefore, we've retained INFO
related object in the draft mibs.

>
> sipSummaryTotalTransactions: description should indicate what a
> transaction stateless proxy does with this counter (probably leaves it
> at 0).

ok. we added...
 "For a transaction stateless proxy, this counter is always 0."  
to the description.

>
> sipStatsInfoIns, Outs: shouldn't be given special treatment -- belong
> in the sipStatsExtMethodTable with all the other method extensions.

see the answer regarding sipMethodStatsEntry above.

>
> SipStatusCodesEntry: should "other" class entries be defined, for
> status codes 700 and up?

ok. we added two new object to the sipStatusCodesTable:
  sipStatsOtherClassesIns
  sipStatsOtherClassesOuts

>
> sipStatsRedirClassIns, Outs: 3xx responses don't necessarily come from
> Redirect Servers -- UAs could be set up to forward calls, for
> instance.  Hence the phrase "taken by a Redirect Server" in the
> description is inappropriate.

ok. we removed the phrase.

>
> sipStatsServerFailClassIns, Outs: final sentence of description
> defines SIP protocol behaviour, not SNMP Agent behaviour, hence should
> be omitted.

ok.  we removed the final sentence from the descriptions.

>
> sipStatsGlobalFailClassIns, Outs: ditto

ok.  we removed the final sentence from the descriptions.

>
> sipStatsExtMethodStatus: description is a bit sparse.  Would something
> more along the lines of the description for sipCommonStatusCodeStatus
> not be desirable here too?

yes, we fleshed out the description with the same text you reference.

>
> sipStatusCodeNotifTo, From, CallId, CSeq: do the reported values
> include the header keywords themselves, or only the part following the
> colon? (e.g.) "From:xx..x" vs. "xx..x"

ok.  we added to the descriptions saying "header name" is part
of the value and examples were given.

>
> sipCurrentTransTable: need something be said about transaction
> stateless proxies?

ok.  we added words that this table and sipTransactionTable do not
apply to transaction stateless proxies.

>
> sipCurrentTransEntry: typo in description -- should be "entity's"
> rather than "entities'".

fixed typo.

>
> SipTransactionEntry: need an object identifying the method which
> initiated the transaction.

ok.  we added a new object ... sipTransMethod (SnmpAdminString)...
to the table.

>
> sipTransTo, From, CallId, CSeq: do the reported values include the
> header keywords themselves, or only the part following the colon?
> (e.g.) "From:xx..x" vs. "xx..x"

ok. we added to the descriptions saying "header name" is part
of the value and examples were given.
 
>
> sipTransState: most of these states apply only to INVITE transactions,
> and  some of them (null, completed, confirmed) do not apply to
> transactions currently in process.  I would suggest instead capturing
> the latest activity in the transaction.  This has two parts: direction
> (received/sent) and status code value or request (the latter being
> either the initiating request or ACK).

we attempted to align the states with bis05, but it proved difficult
to reconcile the differences between rfc2543 and bis05.  some states
match for INVITES while not for other methods and vice versa.
therefore, we did not change any state values in the mib. 
we adding text to the description noting that not all values of the
object are applicable to all transaction types.   is that ok, tom?

we did add one new string object to deal with the "latest activity"
issue you raised.  we gave examples of what that string value might
look like for both direction and requests vs. responses.
(see sipTransActivityInfo object in next revision)

>
> sipTransExpiry: behaviour will be affected by the outcome of my
> initial remark on sipInviteTimeout.

<<< J-F, please check... this is suppose to match up w/ or be in
    line with the answer to the first comment>>>

>
> sipTransCallingPartyContentType, sipTransCalledPartyContentType: nice
> try, but it doesn't work.  Content type varies from message to message
> within a transaction.  Perhaps these objects could record the
> aggregation of content types over all messages so far passed in the
> transaction -- that would reflect your intent.

not sure we understood your suggestion, but it sounded like too
much information and too complicated, so we punted ;)... removed
the objects from the mib.


>
>
> SipCommonStatsRetryEntry: as with sipMethodStatsEntry, the INFO method
> should be treated like all other extensions, rather than appear
> explicitly in this table.

same answer as given above wrt why we included and wish to retain
INFO related objects.

>
> sipOtherStatsEntry: typo in description -- should be "entity's" rather
> than "entities'".

fixed typo.

>
> sipNotifApplIndex: doesn't point to the actual status code being
> monitored.  Shouldn't it be the same structure as the index of
> sipCommonStatusCodeTable?

we had already discovered this.  we fixed it by including in/out
counter objects from sipCommonStatusCodeTable.  the applIndex
will be implicitly conveyed by these objects' OIDs.

>
> SIP-UA-MIB
> ==========
>
> General comment on configuration: should there be a requirement to
> populate the SIP-COMMON-MIB data for each entity before populating
> this MIB?  How is this expressed?

we don't believe we need (should) provide this level of detailed
guidance in the MIB.  it ventures too far into the realm of
implementation.

>
> sipUAMIBNotifs is empty.

it was a placeholder for the future.  not notifs were identified so
we've removed it.

>
> Where is the definition of sipUAStats??

another placeholder.  none were ever identified.  we've removed it.

>
> sipUACfgSipServerEntry: should say that applIndex for each entity
> instance has the same value as used for that instance in the tables of
> SIP-COMMON-MIB.

ok.  we added...
"The same value of applIndex used in the corresponding
SIP-COMMON-MIB is used here."
to the description.

>
> Might it be desirable to configure the UA's Contact address?

providing this turned out to be more complicated than initially
thought.  we first thought the contact address could only be
present in a limited set of request and responses.  it turns out
to be a larger set than expected.  moreover, we don't think people
will really want to use the mib to configure this because the
contact field is very user dependent and is likely to be better
controlled in the context of a application on top of sip.
that can take us away from pure sip protocol mgmt - which should
be the focus of these mibs.   therefore, we've not done anything
in the mibs regarding this comment.

>
> SIP-SERVER-MIB
> ==============
>
> General comment on configuration: should there be a requirement to
> populate the SIP-COMMON-MIB data for each entity before populating
> this MIB?  How is this expressed?

again, we don't believe we need (should) provide this level of detailed
guidance in the MIB.  it ventures too far into the realm of
implementation.

>
> sipServerMIB: description has definitions of the different server
> types.  Would it be safer to refer to the RFC instead?  In any event,
> a Proxy does not initiate requests (as indicated in the definition of
> a Redirect Server).  It does propagate them.

it's useful to have explicit text in the mib for the implementor. 
we wish to leave it as-is.
except we have removed the statement in redirect server section.

>
> sipServerCfgEntry: should say that applIndex for each instance has the
> same value as in SIP-COMMON-MIB.  Question: should there be a
> RowStatus object?  Can values be changed on the fly?

part one:  ok.  added...
           "The same value of applIndex used in the corresponding
            SIP-COMMON-MIB is used here." to the description.

part two: we do not wish to add a RowStatus object.  we're not sure
          of a requirement to create/delete server entities in a system.

wrt "changing on the fly"... it would be implementation specific.

>
> SipProxyCfgEntry: should there be a RowStatus object?

we do not wish to add a RowStatus object.  we're not sure
of a requirement to create/delete server entities in a system.

>
> SipRegCfgEntry: ditto

ditto ;)

>
> sipContactPreference: typed as an OCTET STRING.  Couldn't that be an
> IA5String, or is that not allowed in SNMP?

we changed the object to be a SnmpAdminString.


please let us know if you have and concerns/doubts about how we've
addressed your questions/issues.   once we've pulled together the
rev -04 of the draft, we'll pass it along to you for a final review.

thank you, tom!
SIP MIB Team

Kevin Lingle, Cisco
Joon Maeng, ipDialog
David Walker, SS8 Networks
Jean-Francios Mule

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

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police/
 Sometimes I think I understand everything, then I regain consciousness.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------_=_NextPart_001_01C1A872.58ABB270-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 02:33:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27481 for ; Tue, 29 Jan 2002 02:33:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA12562 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 02:32:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06677; Tue, 29 Jan 2002 01:54:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06648 for ; Tue, 29 Jan 2002 01:54:09 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18690 for ; Tue, 29 Jan 2002 01:54:06 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0T6s4io004711; Tue, 29 Jan 2002 08:54:04 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.18188.392456.823741@harjus.eng.song.fi> Date: Tue, 29 Jan 2002 08:54:04 +0200 To: Michael Thomas Cc: "Peterson, Jon" , sip@ietf.org Subject: [Sip] Bis-06 and Deprecating UDP In-Reply-To: <15445.60276.858845.659265@thomasm-u1.cisco.com> References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> <15445.60276.858845.659265@thomasm-u1.cisco.com> X-Mailer: VM 7.00 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas writes: > Frankly, I think this debate would be much better > served by talking about what the *real* > implication is here: deprecating UDP. Are you > and the rest of the authors ready to do that? i'm not an author, but a couple of weeks ago we had (and i guess still have) problems with udp fragmentation. now if udp would also require ipsec, then there is one more good argument to deprecate udp (as i already suggested in connection with the udp problems). -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 02:55:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27675 for ; Tue, 29 Jan 2002 02:55:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA13402 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 02:55:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06546; Tue, 29 Jan 2002 01:52:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06518 for ; Tue, 29 Jan 2002 01:52:37 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18680 for ; Tue, 29 Jan 2002 01:52:35 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0T6miio004706; Tue, 29 Jan 2002 08:48:44 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.17867.957993.24106@harjus.eng.song.fi> Date: Tue, 29 Jan 2002 08:48:43 +0200 To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] TLS section In-Reply-To: <70565611B164D511957A001083FCDD56CAAE4C@VA02> References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> X-Mailer: VM 7.00 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > Today, SIP clients can use UDP without using IPSec, and that won't change if > we make IPSec mandatory to implement. Now that UDP and TCP are both > mandatory in UAs, clients have a choice - either use UDP, which has no > recommended lower-layer security mechanism in the specification, or use TCP, > which you can secure with TLS. i don't know ipsec well, but from ipsec vpn stuff i have got an impression that setting up ipsec sessions requires either some kind of pki or pre-shared keys, whereas i can do my internet banking over tls without that. i definitely don't want to make the sip ua any more complicated to configure than what it already is. can someone confirm or deny that if i run sip/udp/ipsec, there is no additional configuration in the ua because of ipsec? if additional configuration is needed, then i'm STRONGLY against mandating ipsec. i know that if i would use hip instead of ipsec, there would be no configuration needed, because in hip each party can generate its own keys without coordination with the other parties. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 03:19:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27915 for ; Tue, 29 Jan 2002 03:19:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA14754 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 03:19:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12314; Tue, 29 Jan 2002 02:30:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12269 for ; Tue, 29 Jan 2002 02:30:29 -0500 (EST) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27450 for ; Tue, 29 Jan 2002 02:30:27 -0500 (EST) Received: from jariws1 ([62.248.147.36]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020129073028.BVSW1076.fep06-app.kolumbus.fi@jariws1>; Tue, 29 Jan 2002 09:30:28 +0200 Message-ID: <002601c1a896$d31c69e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Juha Heinanen" , "Peterson, Jon" Cc: "'Michael Thomas'" , References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> <15446.17867.957993.24106@harjus.eng.song.fi> Subject: Re: [Sip] TLS section Date: Tue, 29 Jan 2002 09:30:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Juha, > i don't know ipsec well, but from ipsec vpn stuff i have got an > impression that setting up ipsec sessions requires either some kind of > pki or pre-shared keys, whereas i can do my internet banking over tls > without that. Both IPsec and TLS require some sort of authentication set-up. TLS has just one possibility, PKI, and is typically used with the current web server PKI hierarchy. IPsec does that as well, but also has optional pre-shared keys as an alternative. TLS configs are usually in your browser's security setup window while IPsec configs are usually in the OS setups, though they sometimes can also be controlled from an application via commands or APIs. One difference IPsec and TLS typically have is that TLS may be run in one direction only, where only the server side is being authenticated. This lessens the need to enroll certs for the clients, which could be major issue. However, I'm not sure this is true fundamental difference in the protocols. At least some IPsec implementations I know can be configured to accept self-signed certs. Hence, if the clients generate their own certs (but don't enroll them anywhere), require the same CA roots from the server as TLS does, and if servers accept self-signed certs I think the effect is the same as in TLS. > i definitely don't want to make the sip ua any more complicated to > configure than what it already is. can someone confirm or deny that if > i run sip/udp/ipsec, there is no additional configuration in the ua > because of ipsec? if additional configuration is needed, then i'm > STRONGLY against mandating ipsec. Different configuration than in the TLS case, but in both cases some configuration is indeed needed. All this can be hidden from the user and roots can default to Verisign, but some configuration is needed. > i know that if i would use hip instead of ipsec, there would be no > configuration needed, because in hip each party can generate its own > keys without coordination with the other parties. HIP can indeed do this, but that doesn't mean that if you generated your own keys I'm ready accept your INVITEs. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 04:11:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28445 for ; Tue, 29 Jan 2002 04:11:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA17542 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 04:11:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14147; Tue, 29 Jan 2002 03:04:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14118 for ; Tue, 29 Jan 2002 03:04:11 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27825 for ; Tue, 29 Jan 2002 03:04:08 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0T845io004762; Tue, 29 Jan 2002 10:04:05 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.22389.541083.967570@harjus.eng.song.fi> Date: Tue, 29 Jan 2002 10:04:05 +0200 To: "Jari Arkko" Cc: "Peterson, Jon" , "'Michael Thomas'" , Subject: Re: [Sip] TLS section In-Reply-To: <002601c1a896$d31c69e0$8a1b6e0a@arenanet.fi> References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> <15446.17867.957993.24106@harjus.eng.song.fi> <002601c1a896$d31c69e0$8a1b6e0a@arenanet.fi> X-Mailer: VM 7.00 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jari Arkko writes: > Different configuration than in the TLS case, but in both cases some > configuration is indeed needed. All this can be hidden from the user > and roots can default to Verisign, but some configuration is needed. i don't get this. are people suggesting that if i use ipsec then the proxy server doesn't anymore need to authenticate the ua with username/password like it is done today with digest or basic authentication? my understanding is that ipsec (and may be also tls) doesn't authenticate the user of the computer, but only the computer itself. if so, it could not replace the username/password authentication, but would be just used to protect the integrity and privacy of the authentication process. this is why i can do my banking from anyone's browser. if username/password authentication is always used anyway, then there should be no need to authenticate the parties at the underlying transport (ipsec or tls) layer, right? it would be enough that the transport provides security and integrity of the username/password authentication process. therefore, i don't see any need for the transport to use any kind of pki or pre-shared key stuff, and therefore i don't see any need for the user to configure anything in the ua because of the transport. in summary, if i use username/password authentication, then the sip spec MUST NOT mandate any transport layer security solution that requires ANY authentication of the parties at the transport layer. a solution that can make sure that the communication channel is secure and integrated, MUST be sufficient. > HIP can indeed do this, but that doesn't mean that if you generated your > own keys I'm ready accept your INVITEs. of course not. you would accept my invite because of my username/password. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 04:28:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28745 for ; Tue, 29 Jan 2002 04:28:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18235 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 04:28:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15808; Tue, 29 Jan 2002 03:39:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15779 for ; Tue, 29 Jan 2002 03:39:53 -0500 (EST) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28161 for ; Tue, 29 Jan 2002 03:39:50 -0500 (EST) Received: from jariws1 ([62.248.147.36]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020129083952.CNIA1076.fep06-app.kolumbus.fi@jariws1>; Tue, 29 Jan 2002 10:39:52 +0200 Message-ID: <004501c1a8a0$853102e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Juha Heinanen" Cc: "Peterson, Jon" , "'Michael Thomas'" , References: <70565611B164D511957A001083FCDD56CAAE4C@VA02><15446.17867.957993.24106@harjus.eng.song.fi><002601c1a896$d31c69e0$8a1b6e0a@arenanet.fi> <15446.22389.541083.967570@harjus.eng.song.fi> Subject: Re: [Sip] TLS section Date: Tue, 29 Jan 2002 10:39:52 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > i don't get this. are people suggesting that if i use ipsec then the > proxy server doesn't anymore need to authenticate the ua with > username/password like it is done today with digest or basic > authentication? > > my understanding is that ipsec (and may be also tls) doesn't > authenticate the user of the computer, but only the computer itself. if > so, it could not replace the username/password authentication, but would > be just used to protect the integrity and privacy of the authentication > process. this is why i can do my banking from anyone's browser. Specifically, in your banking application the bank actually *does* get authenticated using certs, and as a side-effect a protected "tunnel" is established to protect your communications. [With no certs or anything for the bank side, protected communications could not be securely established!] After all this, *you* get authenticated by the passwords. > if username/password authentication is always used anyway, then there > should be no need to authenticate the parties at the underlying > transport (ipsec or tls) layer, right? it would be enough that the > transport provides security and integrity of the username/password > authentication process. therefore, i don't see any need for the > transport to use any kind of pki or pre-shared key stuff, and therefore > i don't see any need for the user to configure anything in the ua > because of the transport. See above. Getting security and integrity for the tranport does force you to configure something - or at least your browser vendor to default something for you. The question that can be asked, however, is whether TLS-like one-sided thing or TLS/IPSec-like two-sided thing should be used. It seems that both TLS and IPsec are capable of both alternatives. > in summary, if i use username/password authentication, then the sip spec > MUST NOT mandate any transport layer security solution that requires ANY > authentication of the parties at the transport layer. a solution that > can make sure that the communication channel is secure and integrated, > MUST be sufficient. > > > HIP can indeed do this, but that doesn't mean that if you generated your > > own keys I'm ready accept your INVITEs. > > of course not. you would accept my invite because of my > username/password. Ah, now I see better what you mean. But assuming you *are* trusting the integrity and confidentiality of your "transport", do you know if HIP is secure against MitM, if there's no configuration? You seem to be implying something akin to the opportunistic IPsec methods, but I'm not sure if that has been defined for HIP yet. Jari _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 05:03:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29115 for ; Tue, 29 Jan 2002 05:03:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20382 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 05:03:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17805; Tue, 29 Jan 2002 04:19:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17772 for ; Tue, 29 Jan 2002 04:19:05 -0500 (EST) Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28599 for ; Tue, 29 Jan 2002 04:19:03 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g0T9FAg12307; Tue, 29 Jan 2002 04:15:10 -0500 Message-Id: <200201290915.g0T9FAg12307@minotaur.nge.isi.edu> To: "Peterson, Jon" cc: "'Michael Thomas'" , "'Rosen, Brian'" , sip@ietf.org Reply-To: mankin@isi.edu In-reply-to: Your message of Mon, 28 Jan 2002 18:31:17 -0600. <70565611B164D511957A001083FCDD56CAAE4E@VA02> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Jan 2002 04:15:10 -0500 From: Allison Mankin Subject: [Sip] IESG requirements (was Re: TLS section) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > I thought that we were charged by the IESG to identify the tools could be > used to secure our protocol - not to put out a protocol and assume somebody > else in the IETF, or worse various vendors/service providers, must determine > how to apply security to it before it can be deployed. > Jon has this exactly right. The IESG has required the SIP spec to describe a threat model and provide security mechanisms to address the threats, otherwise bis will not be approved. > I understand that we need to choose something, not exclusively but > minimally, that goes into our Security Considerations section. Again, this > is perhaps something for the IESG to clarify. > IESG requires the spec to provide a minimum interopable set of mechanisms. Each, where appropriate, must define minimum mandatory-to- implement encryption and authentication algorithms. Other security implementations are not excluded; also IETF specs do not mandate use or how security is configured in use, just the presence in products of interopable implementations. A minimum interoperable IPsec specification for SIP is a TODO item (for the sip security design team, I think), because those who expect to deploy SIP with IPsec will benefit from shared recommendations on it. An IPsec profile includes specific minimum algorithms, as well as keying techniques/modes, and statements of limitations. Allison Transport Area Director for SIP _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 08:18:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02223 for ; Tue, 29 Jan 2002 08:18:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA29518 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 08:18:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27291; Tue, 29 Jan 2002 07:43:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27260 for ; Tue, 29 Jan 2002 07:43:35 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01374; Tue, 29 Jan 2002 07:43:32 -0500 (EST) Message-Id: <200201291243.HAA01374@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 29 Jan 2002 07:43:32 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-rfc2543bis-06.txt,.ps,.pdf Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP: Session Initiation Protocol Author(s) : J. Rosenberg, H. Schulzrinne et al. Filename : draft-ietf-sip-rfc2543bis-06.txt,.ps,.pdf Pages : 278 Date : 28-Jan-02 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution and multimedia conferences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-rfc2543bis-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-rfc2543bis-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: <20020128151233.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020128151233.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 08:46:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02872 for ; Tue, 29 Jan 2002 08:46:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA01616 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 08:46:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00163; Tue, 29 Jan 2002 08:28:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00128 for ; Tue, 29 Jan 2002 08:28:37 -0500 (EST) Received: from imo-r04.mx.aol.com (imo-r04.mx.aol.com [152.163.225.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02485 for ; Tue, 29 Jan 2002 08:28:32 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r04.mx.aol.com (mail_out_v31_r1.26.) id l.ac.21b1f04a (4568) for ; Tue, 29 Jan 2002 08:27:58 -0500 (EST) Message-ID: Date: Tue, 29 Jan 2002 08:27:58 EST Subject: Re: [Sip] bis-06 now available! To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In a message dated 1/28/02 6:32:35 AM Eastern Standard Time, jdrosen@dynamicsoft.com writes: > Folks, > > I have just submitted an update to bis. Until it appears in the > archives, you can pick it up at: > > > Comments, questions, and criticisms (and I'm sure people will have them) > are welcome. > > Thanks, > Jonathan R. > Amazing work Jonathan and all. History of document size: RFC2543 331k bytes -02 381k bytes -04 449k bytes -05 510 k bytes -06 667k bytes (Largest RFC published to date - 585k bytes) Will we reach 1meg before the next SIP RFC is published? 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 daemon@optimus.ietf.org Tue Jan 29 08:52:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03065 for ; Tue, 29 Jan 2002 08:52:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA02033 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 08:52:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00197; Tue, 29 Jan 2002 08:28:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00135 for ; Tue, 29 Jan 2002 08:28:37 -0500 (EST) Received: from imo-r03.mx.aol.com (imo-r03.mx.aol.com [152.163.225.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02487 for ; Tue, 29 Jan 2002 08:28:34 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-r03.mx.aol.com (mail_out_v31_r1.26.) id g.168.7e29cf2 (4568); Tue, 29 Jan 2002 08:27:46 -0500 (EST) Message-ID: <168.7e29cf2.2987fd5d@aol.com> Date: Tue, 29 Jan 2002 08:27:57 EST Subject: Re: [Sip] calling number blocking at sip/isup gateway To: jon.peterson@neustar.biz, sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In a message dated 1/27/02 4:56:48 PM Eastern Standard Time, jon.peterson@neustar.biz writes: > What a long thread. > etc. Jon, Great summary of what is needed and what is not. There have been a lot of protocol hacks mentioned in the last week, including putting a "bogus url" in the From header or having the gateway replace the real calling party number with some "gateway number". Also there have been suggestions that, somehow, encryption was part of the solution for privacy of calling party ID and that a "coded secret and a decoder ring" could be used. But encryption would only address the issue of preventing someone in the middle from seeing the ID, which is not the issue here. In the general case, we're talking about a calling line ID capability for which the calling and called party have nothing in common, certainly not a shared secret. I agree, there is certainly the case in which there is simply no Calling party number in the signaling (e.g., From=anonymous in the INVITE) when one element doesn't trust the next to preserve privacy. But there is the other case in which it trusts the next network element and includes the ID (maybe because the law or the network policy requires it) and it also includes an indicator of what privacy procedures apply. If every network portion is trusted, the ID can be passed to the final "switch" which then doesn't deliver it to the called party. So just because you get "unavailable" on your Caller-ID screen doesn't mean that it wasn't in the IAM, but it could. Of course, the problem for SIP is the possible absence of any trusted device that functions as the final "switch". However, because of other security concerns, a real IP telephone service provider would require that it knows the identity of the calling party and the model for this service must be based on a presumption that the calling party can trust the service provider. Therefore, in this case, the From must contain a correct number, and the gateway may remove it (after verifying it). The case of the calling party leaving out the From can not be used in a "tariffed" (if I can use that term) telephone service. While the SIP protocol may allow it to be left out, the service provider may require it before allowing call setup. I think this whole discussion should be taken to the SIPPING list until there is an agreement on the functional requirements. 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 daemon@optimus.ietf.org Tue Jan 29 10:48:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06690 for ; Tue, 29 Jan 2002 10:48:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08623 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 10:48:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06365; Tue, 29 Jan 2002 10:08:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06332 for ; Tue, 29 Jan 2002 10:08:56 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05325 for ; Tue, 29 Jan 2002 10:08:53 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0TF8cio004992; Tue, 29 Jan 2002 17:08:38 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.47862.132732.884862@harjus.eng.song.fi> Date: Tue, 29 Jan 2002 17:08:38 +0200 To: Mpierce1@aol.com Cc: jon.peterson@neustar.biz, sip@ietf.org Subject: Re: [Sip] calling number blocking at sip/isup gateway In-Reply-To: <168.7e29cf2.2987fd5d@aol.com> References: <168.7e29cf2.2987fd5d@aol.com> X-Mailer: VM 7.00 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit mike's summary we well reflects my thinking and the reasons why i brought this up in the first place. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 11:21:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08096 for ; Tue, 29 Jan 2002 11:21:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10743 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 11:21:13 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08940; Tue, 29 Jan 2002 10:54:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08909 for ; Tue, 29 Jan 2002 10:54:55 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06936 for ; Tue, 29 Jan 2002 10:54:51 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g0TFsCN09270; Tue, 29 Jan 2002 09:54:12 -0600 Message-Id: <200201291554.g0TFsCN09270@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: "Peterson, Jon" , "'Rosen, Brian'" , "'Michael Thomas'" , sip@ietf.org Subject: Re: [Sip] TLS section Date: Tue, 29 Jan 2002 09:54:11 -0600 X-Mailer: KMail [version 1.3.2] References: <70565611B164D511957A001083FCDD56CAAE49@VA02> In-Reply-To: <70565611B164D511957A001083FCDD56CAAE49@VA02> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Jon asked: > I think it would be interesting first to learn who on this > distribution prefers to provide lower-layer security for SIP with > IPSec rather than TLS, and then moreover whether those that do prefer > IPSec would rather use transport mode (host-by-host, integrated with > SIP applications) or tunnel mode (not integrated with SIP > applications, using security gateways). Making either one a "MUST" is a BAD idea. It means that far too many smaller systems, or systems with other security mechanisms, can never comply with the specification. The implementors, forced to selectively ignore some requirements of the specification, are likely to ignore other parts of the spec as well. It's kind of like "having shot the security gaurd, you might as well go ahead and rob the bank -- the penalty is not any worse". Or those implementors may just demonstrate good sense and switch to an implementable protocol and ignore our further academic and irrrelevant ramblings. Requirements which significantly impact applicability must be carefully bounded, with specific exemptions granted and alternatives allowed. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 11:35:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08530 for ; Tue, 29 Jan 2002 11:35:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA11553 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 11:35:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10310; Tue, 29 Jan 2002 11:13:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10284 for ; Tue, 29 Jan 2002 11:13:36 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07787 for ; Tue, 29 Jan 2002 11:13:32 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18674; Tue, 29 Jan 2002 11:13:02 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17299; Tue, 29 Jan 2002 11:13:01 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Jan 2002 11:13:00 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57C85D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dean Willis'" , "Peterson, Jon" , "Rosen, Brian" , "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] TLS section Date: Tue, 29 Jan 2002 11:13:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I know this argument well; it's the "any security takes too much cpu/memory". I don't buy it. At this point, without designing an entirely new crypto package for SIP, TLS and IPSec are the only viable candidates for hop-by-hop security. I don't thing the cpu/memory requirements are much different for them. The basic difference has been hashed out on this list for a while - TLS is TCP only, applications level, with a set of conventions on PKI that make the solution tractable for servers, and less so for UAs. IPSec is a transport layer, UDP or TCP, lacking the above conventions, but with widely implemented mechanisms for the kind of secure-tunnel-between-protected-enclave kind of hop-by-hop that we need. For me, the (minor) win with IPSec is that you don't change the app - you enable the IPsec stuff on the transport. I don't think the threats that have confidentiality are the big ones; the threats that need a reasonable degree of authentication (NOT user authentication, server/device authentication) and integrity protection are the ones I really worry about. YMMV If 3G wants to ignore the must implement bit in the UA because they have their own crypto in the handset-to-base-station link, fine. We can't write the spec that way. First hop can be important, but it's rarely the weak point; you almost always have a proxy server between the UA and the big-bad-world. I'd actually like the spec to say that first hop/last hop security is not mandatory to implement, because I think that's the real world, but I'm sanguine about trying to get that through the IESG. The real privacy advocates want to see tight confidentiality end to end, and if you don't implement that in the UA, you don't get it. The only reason we might be able to get away with HMAC-MD-5-NULL is that there are quite a few RFCs that have that as the minimum. I am actually okay with adding DES to the minimum set, but I don't think we need it. The idea that the MINIMUM set includes AES is, to my way of thinking, a problem, because there are very few implementations today. Long term, that is the way I'm heading, let there be no doubt, but do we mandate that for an RFC releasing next month? Brian > -----Original Message----- > From: Dean Willis [mailto:dwillis@greycouncil.com] > Sent: Tuesday, January 29, 2002 10:54 AM > To: Peterson, Jon; 'Rosen, Brian'; 'Michael Thomas'; sip@ietf.org > Subject: Re: [Sip] TLS section > > > Jon asked: > > I think it would be interesting first to learn who on this > > distribution prefers to provide lower-layer security for SIP with > > IPSec rather than TLS, and then moreover whether those that > do prefer > > IPSec would rather use transport mode (host-by-host, integrated with > > SIP applications) or tunnel mode (not integrated with SIP > > applications, using security gateways). > > Making either one a "MUST" is a BAD idea. It means that far too many > smaller systems, or systems with other security mechanisms, can never > comply with the specification. > > The implementors, forced to selectively ignore some > requirements of the > specification, are likely to ignore other parts of the spec as well. > It's kind of like "having shot the security gaurd, you might > as well go > ahead and rob the bank -- the penalty is not any worse". > > Or those implementors may just demonstrate good sense and > switch to an > implementable protocol and ignore our further academic and > irrrelevant > ramblings. > > Requirements which significantly impact applicability must be > carefully > bounded, with specific exemptions granted and alternatives allowed. > > -- > Dean > *********This message is definately not confidential and it does not matter in practice who sees it and whether or not it goes astray. No harm whatever would come to anyone even if it were published in a national newspaper. I apologise therefore for the unnecessary and irritating message that may or may not follow (I don't know because it is invisible to me)!!!!****** This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachment, use the contents for any purposes, or disclose the contents to any other person: to do so could be a breach of confidence. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 12:10:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09672 for ; Tue, 29 Jan 2002 12:10:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14720 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 12:10:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11904; Tue, 29 Jan 2002 11:40:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11878 for ; Tue, 29 Jan 2002 11:40:24 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08769 for ; Tue, 29 Jan 2002 11:40:20 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0TGaYh15029; Tue, 29 Jan 2002 10:36:34 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g0TGaY017027; Tue, 29 Jan 2002 10:36:34 -0600 (CST) Received: from lmf.ericsson.se (rmt160178.am.ericsson.se [138.85.160.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA28149; Tue, 29 Jan 2002 10:36:31 -0600 (CST) Message-ID: <3C56D6A7.86BC5E9A@lmf.ericsson.se> Date: Tue, 29 Jan 2002 19:06:47 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> <15445.60276.858845.659265@thomasm-u1.cisco.com> <15446.18188.392456.823741@harjus.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, UDP is still useful when you are sending small messages. If you want to send large messages, use TCP. But if, by any chance, your message is small, you can avoid the three way handshake by using UDP. I do not see why because some (or many) applications will use large messages, the rest of the applications that do not use them have to pay the price of the 3-way handshake as well. Regards, Gonzalo Juha Heinanen wrote: > > Michael Thomas writes: > > > Frankly, I think this debate would be much better > > served by talking about what the *real* > > implication is here: deprecating UDP. Are you > > and the rest of the authors ready to do that? > > i'm not an author, but a couple of weeks ago we had (and i guess still > have) problems with udp fragmentation. now if udp would also require > ipsec, then there is one more good argument to deprecate udp (as i > already suggested in connection with the udp problems). > > -- 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 -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 12:12:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09722 for ; Tue, 29 Jan 2002 12:12:18 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14850 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 12:12:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12170; Tue, 29 Jan 2002 11:43:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12140 for ; Tue, 29 Jan 2002 11:43:33 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08839 for ; Tue, 29 Jan 2002 11:43:11 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0TGevd23528; Tue, 29 Jan 2002 08:42:31 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT77020; Tue, 29 Jan 2002 08:40:25 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA21500; Tue, 29 Jan 2002 08:40:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.53399.553211.680133@thomasm-u1.cisco.com> Date: Tue, 29 Jan 2002 08:40:55 -0800 (PST) To: "Rosen, Brian" Cc: "'Dean Willis'" , "Peterson, Jon" , "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] TLS section In-Reply-To: <313680C9A886D511A06000204840E1CF57C85D@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF57C85D@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rosen, Brian writes: > I know this argument well; it's the "any security takes too much > cpu/memory". I don't buy it. In fact, the minimum requirement that I've been recommending can and has been implemented in 6000 bytes of code. Anybody who can't afford that can't afford *any* crypto whatsoever since 5kb of that was just for the hash. This can be done at app layer, the kernel, or as a bump in the stack. There is just no excuse at all not to at least do this; it should be a MUST. Yet, this very simple thing that could be done, widely implemented and deployed is being sent off into Siberia by the IESG in favor of something that requires 400kb of code, doesn't meet the basic requirements, and isn't even a MUST. This is insane. 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 daemon@optimus.ietf.org Tue Jan 29 12:13:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09769 for ; Tue, 29 Jan 2002 12:13:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA14901 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 12:13:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11802; Tue, 29 Jan 2002 11:38:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11678 for ; Tue, 29 Jan 2002 11:38:14 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08637 for ; Tue, 29 Jan 2002 11:38:09 -0500 (EST) From: bernhard.honeisen@nokia.com Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g0TGcRi26856 for ; Tue, 29 Jan 2002 18:38:27 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 29 Jan 2002 18:38:10 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 29 Jan 2002 18:38:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Loose Routing draft Date: Tue, 29 Jan 2002 18:38:11 +0200 Message-ID: Thread-Topic: [Sip] Loose Routing draft Thread-Index: AcGlG0MqnNJi9yWaShyUgBzrVsXPPAC4HBIA To: Cc: X-OriginalArrivalTime: 29 Jan 2002 16:38:11.0734 (UTC) FILETIME=[5736DB60:01C1A8E3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA11679 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Robert! Comments inline. cheers, Bernie >-----Original Message----- >From: ext Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: 24. January 2002 23:07 >To: 'sip@ietf.org' >Subject: FW: [Sip] Loose Routing draft > > >Resend - it looks like mail issues ate my first attempt. >Apologies if this appears twice. > >-----Original Message----- > >> >> I would go one step further, and at least discourage >> >> people from >> >> loose-routing _subsequent_ requests (e.g. >> >> re-INVIVEs). >> > >> >I see no reason to do this. Loose routing is all >> >about local policy. As long as the strict >> >route is honored, it shouldn't matter what happens >> >in subsequent requests. >> >> Especially in cases, where you some element keeps >> session state it should get also e.g. the BYE >> concerning this session, in order to release the >> resources. If a proxy before is allowed to just >> modify the Request-URI (which has been recorded >> earlier in Record-Route), it cannot be totally >> sure anymore. >> This is way, we cannot claim the loose-routing >> to be 100% backwards compatible, if such things are >> possible. > >The restrictions on the loose route policies are >intended to make sure that any resource listed on a >route set gets visited - it does not give a proxy >license to say the request doesn't really need to >visit the rest of the Route stack. It does allow >other things to be visited along the way. > >That said, here's an example of the kind of thing >that's concerning you (let me know if I misunderstood >where you were going). Consider this BYE >with a Route header established by Record-Route >in a previous INVITE: > >(sent to p1) >BYE sip:res@p1 >Route , > >Assume p1 has a policy of popping the topmost >route header into the reqeust-URI, but then sending >the request off to some third place, > >(sent to p3) >BYE sip:res@p2 >Route > >Now if p3 has a policy to just rewrite the request-URI >and sent things along to whatever was indicated in the >topmost route, it might emit > >(sent to B) >BYE sip:newres@elsewhere >Route > >p2 never sees the request - this is bad. > >It turns out that nothing is special about this >being a subsequent request - you can construct the >same failure for initial requests. That's right, but in initial requests this is not so important. - Session stateful proxies might hold resources, which are not released timely, if we cannot garantee, that the BYE is coming - The system Record-Routing system is not anymore backwards-compatible, we cannot guarantee anymore the the subsequent requests are routed through this element as forseen by RFC2543 and bis'. >I can propose a restriction that plugs this hole, but >that falls into treating a symptom instead of >treating the problem. What the looseroute text needs to >reflect is that a hop only exercises a non-strict-route >policy when it knows what policy of the next hop is. >If it doesn't have that knowledge, an element needs to >strict route. So, p1 above would not send a request >formatted as it is to a p3 that it didn't expect to send >the request to what the Request-URI explicitly identified. > >So, how would p1 know to expect that? How does p1 know >about such a p3 in the first place? Some administrative >policy gave p1 the information about the existance of p3 >- through protocol or configuration. The thing providing >that configuration must have some knowledge of what p3 >is expected to do. > >RjS > >> >> I have the feeling, that we have to: >> >> 1) be able to distinguish whether a Route >> header has been preloaded or not >> e.g. we could introduce a new Route parameter, >> informing about "preloaded" >Wouldn't help (as above) >> >> 2) maybe even restrict the loose-routing in >> preloaded case so much, that we can ensure that >> every request passes the proxies, which >> had record-routed. > >This is the real goal, whether the request is initial >or within the route-set of an established dialog. > >> >> If we make the difference between pre-loaded and >> not pre-loaded (instead of between first and >> sub-sequest requests), we still can have a (limited) >> loose routing possibility in subsequent requests. >> >> cheers >> Bernie >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 12:25:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10167 for ; Tue, 29 Jan 2002 12:25:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA15480 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 12:25:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12906; Tue, 29 Jan 2002 11:57:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12872 for ; Tue, 29 Jan 2002 11:57:51 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09225 for ; Tue, 29 Jan 2002 11:57:47 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g0TGvGN09741; Tue, 29 Jan 2002 10:57:17 -0600 Message-Id: <200201291657.g0TGvGN09741@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: Mpierce1@aol.com, jon.peterson@neustar.biz, sip@ietf.org Subject: Re: [Sip] calling number blocking at sip/isup gateway Date: Tue, 29 Jan 2002 10:57:14 -0600 X-Mailer: KMail [version 1.3.2] References: <168.7e29cf2.2987fd5d@aol.com> In-Reply-To: <168.7e29cf2.2987fd5d@aol.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Tuesday 29 January 2002 07:27 am, Mpierce1@aol.com wrote: > However, because of other security concerns, a real IP telephone > service provider would require that it knows the identity of the > calling party and the model for this service must be based on a > presumption that the calling party can trust the service provider. > Therefore, in this case, the From must contain a correct number, and > the gateway may remove it (after verifying it). > > The case of the calling party leaving out the From can not be used in > a "tariffed" (if I can use that term) telephone service. While the > SIP protocol may allow it to be left out, the service provider may > require it before allowing call setup. I run a real IP telephone service. Unknown parties may place calls over the Internet to my subscribers. My subscribers's profiles may result in forwarding those calls to a PSTN gateway. PSTN charges originating from this operation are charged back to the subscriber (the called party), not the calling party with whom I have no relationship outside the SIP used to set up the call. It really doesn't matter what the calling party put in their From: field, I still need to complete the call. Now, if they were kind enough to put in a phone number, I can map that into the IAM. But if they didn't, I just can't. Now, there's an interesting question on "authenticating" the phone number that they might have included., but that's a different problem. Even more interesting, I'm going to include any referenceable number from the INVITE in the IAM, regardless of any privacy indicator suggested by the SIP signaling, because that referencable number would have been included in the SIP signal delivered to my subscriber anyhow (The caller DID send it to him), and my job as a gateway oeprator is to get as much of the SIP experience as possible into the call being forwarded to the PSTN. So, here we have a real phone service which conflicts with the behavioral requirements suggested by mpierce's post, as well as a whole can of privacy and transitive trust worms. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 13:11:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11879 for ; Tue, 29 Jan 2002 13:11:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19057 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 13:11:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16600; Tue, 29 Jan 2002 12:32:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16569 for ; Tue, 29 Jan 2002 12:32:54 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10577 for ; Tue, 29 Jan 2002 12:32:47 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id RAA21661; Tue, 29 Jan 2002 17:30:32 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id RAA07545; Tue, 29 Jan 2002 17:32:42 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 10:32:42 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B37199@n0214idc1.oss.level3.com> To: Mpierce1@aol.com, sip@ietf.org Subject: RE: [Sip] bis-06 now available! Date: Tue, 29 Jan 2002 10:32:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > Amazing work Jonathan and all. > > History of document size: > RFC2543 331k bytes > -02 381k bytes > -04 449k bytes > -05 510 k bytes > -06 667k bytes > > (Largest RFC published to date - 585k bytes) > > Will we reach 1meg before the next SIP RFC is published? > > Mike > I'll second that attaboy. Some would argue size doesn't matter ;-) but the content of this draft is excellent. I would like to thank each of the authors for their tireless work improving this specification, plugging the holes, and struggling to reach consensus with the many list participants. Great job. John Hearty Level3 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 13:11:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11895 for ; Tue, 29 Jan 2002 13:11:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19071 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 13:11:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17157; Tue, 29 Jan 2002 12:41:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17128 for ; Tue, 29 Jan 2002 12:41:46 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10822 for ; Tue, 29 Jan 2002 12:41:41 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0THfVio005187; Tue, 29 Jan 2002 19:41:32 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.57035.913124.978379@harjus.eng.song.fi> Date: Tue, 29 Jan 2002 19:41:31 +0200 To: Michael Thomas Cc: "Rosen, Brian" , "'Dean Willis'" , "Peterson, Jon" , sip@ietf.org Subject: RE: [Sip] TLS section In-Reply-To: <15446.53399.553211.680133@thomasm-u1.cisco.com> References: <313680C9A886D511A06000204840E1CF57C85D@whq-msgusr-02.pit.comms.marconi.com> <15446.53399.553211.680133@thomasm-u1.cisco.com> X-Mailer: VM 7.00 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas writes: > > I know this argument well; it's the "any security takes too much > > cpu/memory". I don't buy it. i don't care of cpu/memory, but i get mad if security makes configuration of the ua more difficult than what it is w/o security or if sip phones can't be used without a global pki. so whatever security technology is chosen, it MUST be based on self generated keys so that username/password is the only thing that needs to be configured in the ua for security. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 13:23:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12468 for ; Tue, 29 Jan 2002 13:23:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19972 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 13:23:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17424; Tue, 29 Jan 2002 12:47:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17399 for ; Tue, 29 Jan 2002 12:47:56 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11012 for ; Tue, 29 Jan 2002 12:47:54 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0THlPI18404; Tue, 29 Jan 2002 09:47:25 -0800 (PST) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABX36982; Tue, 29 Jan 2002 09:47:35 -0800 (PST) From: "Cullen Jennings" To: "Michael Thomas" , Subject: RE: [Sip] TLS section Date: Tue, 29 Jan 2002 09:56:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <15446.53399.553211.680133@thomasm-u1.cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Just to help everyone on the list that has not followed all of this (Me if no one else :-) Could you briefly summarize the 6k and 400k solution? > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Michael > Thomas > Sent: Tuesday, January 29, 2002 8:41 AM > To: Rosen, Brian > Cc: 'Dean Willis'; Peterson, Jon; 'Michael Thomas'; sip@ietf.org > Subject: RE: [Sip] TLS section > > > Rosen, Brian writes: > > I know this argument well; it's the "any security takes too much > > cpu/memory". I don't buy it. > > In fact, the minimum requirement that I've been > recommending can and has been implemented in 6000 > bytes of code. Anybody who can't afford that can't > afford *any* crypto whatsoever since 5kb of that > was just for the hash. This can be done at app layer, > the kernel, or as a bump in the stack. There is just > no excuse at all not to at least do this; it should > be a MUST. > > Yet, this very simple thing that could be done, widely > implemented and deployed is being sent off into Siberia > by the IESG in favor of something that requires 400kb > of code, doesn't meet the basic requirements, and > isn't even a MUST. > > This is insane. > > 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 daemon@optimus.ietf.org Tue Jan 29 13:50:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14629 for ; Tue, 29 Jan 2002 13:50:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA21992 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 13:50:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15159; Tue, 29 Jan 2002 12:17:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15118 for ; Tue, 29 Jan 2002 12:17:21 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09931 for ; Tue, 29 Jan 2002 12:17:16 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0THGPd23829; Tue, 29 Jan 2002 09:16:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT77842; Tue, 29 Jan 2002 09:15:29 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA21506; Tue, 29 Jan 2002 09:15:59 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.55503.822947.102040@thomasm-u1.cisco.com> Date: Tue, 29 Jan 2002 09:15:59 -0800 (PST) To: Dean Willis Cc: "Peterson, Jon" , "'Rosen, Brian'" , "'Michael Thomas'" , sip@ietf.org Subject: Re: [Sip] TLS section In-Reply-To: <200201291554.g0TFsCN09270@bdsl.66.12.12.130.gte.net> References: <70565611B164D511957A001083FCDD56CAAE49@VA02> <200201291554.g0TFsCN09270@bdsl.66.12.12.130.gte.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > Jon asked: > > I think it would be interesting first to learn who on this > > distribution prefers to provide lower-layer security for SIP with > > IPSec rather than TLS, and then moreover whether those that do prefer > > IPSec would rather use transport mode (host-by-host, integrated with > > SIP applications) or tunnel mode (not integrated with SIP > > applications, using security gateways). > > Making either one a "MUST" is a BAD idea. It means that far too many > smaller systems, or systems with other security mechanisms, can never > comply with the specification. If you choose TLS, that is correct. If you chose IPsec and are silent on key distribution, that is not correct unless you're going to tell me that we can't get people to burn a maximum of 6kb of code (probably less than 1kb since digest is already a MUST). 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 daemon@optimus.ietf.org Tue Jan 29 13:56:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15578 for ; Tue, 29 Jan 2002 13:56:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22171 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 13:56:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19824; Tue, 29 Jan 2002 13:21:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19791 for ; Tue, 29 Jan 2002 13:21:35 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12306 for ; Tue, 29 Jan 2002 13:21:32 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0TIKvL17974; Tue, 29 Jan 2002 10:20:57 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT79692; Tue, 29 Jan 2002 10:20:17 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA21515; Tue, 29 Jan 2002 10:20:47 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.59391.333686.165897@thomasm-u1.cisco.com> Date: Tue, 29 Jan 2002 10:20:47 -0800 (PST) To: Juha Heinanen Cc: Michael Thomas , "Rosen, Brian" , "'Dean Willis'" , "Peterson, Jon" , sip@ietf.org Subject: RE: [Sip] TLS section In-Reply-To: <15446.57035.913124.978379@harjus.eng.song.fi> References: <313680C9A886D511A06000204840E1CF57C85D@whq-msgusr-02.pit.comms.marconi.com> <15446.53399.553211.680133@thomasm-u1.cisco.com> <15446.57035.913124.978379@harjus.eng.song.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen writes: > Michael Thomas writes: > > > > I know this argument well; it's the "any security takes too much > > > cpu/memory". I don't buy it. > > i don't care of cpu/memory, but i get mad if security makes > configuration of the ua more difficult than what it is w/o security or > if sip phones can't be used without a global pki. so whatever security > technology is chosen, it MUST be based on self generated keys so that > username/password is the only thing that needs to be configured in the > ua for security. Then you should like my proposal. In fact, you could use the exact same key that you use for digest, as well as share the code for MD5. 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 daemon@optimus.ietf.org Tue Jan 29 14:00:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16029 for ; Tue, 29 Jan 2002 14:00:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA22466 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 14:00:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19637; Tue, 29 Jan 2002 13:18:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19604 for ; Tue, 29 Jan 2002 13:18:42 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12179 for ; Tue, 29 Jan 2002 13:18:39 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0TII9d22112; Tue, 29 Jan 2002 10:18:09 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT79606; Tue, 29 Jan 2002 10:17:36 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA21512; Tue, 29 Jan 2002 10:18:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.59230.484846.997422@thomasm-u1.cisco.com> Date: Tue, 29 Jan 2002 10:18:06 -0800 (PST) To: "Cullen Jennings" Cc: "Michael Thomas" , Subject: RE: [Sip] TLS section In-Reply-To: References: <15446.53399.553211.680133@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Cullen Jennings writes: > > Just to help everyone on the list that has not followed all of this (Me if > no one else :-) Could you briefly summarize the 6k and 400k solution? Sure. IPsec make a clear distinction between key distribution and per-message crypto transforms. The base IPsec is described in RFC 2401. It says absolutely nothing about key distribution; it's only requirement is that a symmetric key be bound to a SPI in the IPsec security association database. How that key gets in there is completely out of scope, and one of the valid mechanisms is sneakernet; ie, manual shared keys. While 2401 describes tunnel and transport modes, along with AH and ESP, in the end it also describes how security policy is transformed in security associations. Since it is perfectly valid to have policies which forbid tunnels and, say, AH, I do not think it is too much of a stretch to say that minimal implementations are within the spirit of 2401. In any case, this provably works; I have an interoperable implementation with Freeswan and it took me all of about a day and a half to write my minimal IPsec from scratch. If I knew how to make that public easily (I did this on Cisco's time), I'd make it freely available. If enough people are interested, I'll take on that effort. TLS on the other hand is a package: it defines both the per message transport crypto as well as the key exchange and authentication piece. It does not allow for manual keying at all. The openSSL distribution I compiled required over 400kb of code. While I do not doubt this could be reduced, it is not possible to come anywhere near the small footprint I achieved for minimal ipsec precisely because it cannot be severed from key distribution, PKI's and all the rest. Key distribution code -- with its unfortunate use of krufty ASN.1 -- is quite large. They all suck. They bring things to the table that I think are important (both for IPsec and TLS), but in the end they are quite a large bite to chew for low end widgets -- ie, the kinds of things we want to get SIP into. So for SIP, I think we should be mainly interested in securing SIP messages instead of solving world hunger through PKI navel gazing. A credible and secure system could be built using manual keying with the possible addition of digest where it's not practical to access credentials in the kernel (and this objection is *completely* bogus on most embedded widgets which almost always have access to their kernel or net drivers). We know this model scales. In fact, it's the only model we know for sure will scale. All the rest is conjecture. Thus my proposal is simple, it meets requirements, and it doesn't boil the ocean. The TLS proposal doesn't meet requirements, is bloated, and presupposes infrastructures that do not exist. This really isn't rocket science. 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 daemon@optimus.ietf.org Tue Jan 29 14:30:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17829 for ; Tue, 29 Jan 2002 14:30:02 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24221 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 14:30:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22042; Tue, 29 Jan 2002 13:50:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22011 for ; Tue, 29 Jan 2002 13:50:54 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14705 for ; Tue, 29 Jan 2002 13:50:51 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g0TIo6H01594; Tue, 29 Jan 2002 12:50:06 -0600 Message-Id: <200201291850.g0TIo6H01594@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: Michael Thomas , Dean Willis Subject: Re: [Sip] TLS section Date: Tue, 29 Jan 2002 12:50:04 -0600 X-Mailer: KMail [version 1.3.2] Cc: "Peterson, Jon" , "'Rosen, Brian'" , "'Michael Thomas'" , sip@ietf.org References: <70565611B164D511957A001083FCDD56CAAE49@VA02> <200201291554.g0TFsCN09270@bdsl.66.12.12.130.gte.net> <15446.55503.822947.102040@thomasm-u1.cisco.com> In-Reply-To: <15446.55503.822947.102040@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Tuesday 29 January 2002 11:15 am, Michael Thomas wrote: > Dean Willis writes: > > Jon asked: > > > I think it would be interesting first to learn who on this > > > distribution prefers to provide lower-layer security for SIP > > > with IPSec rather than TLS, and then moreover whether those that > > > do prefer IPSec would rather use transport mode (host-by-host, > > > integrated with SIP applications) or tunnel mode (not integrated > > > with SIP applications, using security gateways). > > > > Making either one a "MUST" is a BAD idea. It means that far too > > many smaller systems, or systems with other security mechanisms, > > can never comply with the specification. > > If you choose TLS, that is correct. If you > chose IPsec and are silent on key distribution, > that is not correct unless you're going to tell > me that we can't get people to burn a maximum > of 6kb of code (probably less than 1kb since digest > is already a MUST). Just make compliance with both TLS and IPSEC (minimum profile as specified) a very strongly worded SHOULD and I'll be reasonably happy. Why force double-protection on links that already have a layer-2 protection which has key-management in place to coordinate with app-layer DIGEST? These mobile devices already have AKA software and in many cases DES hardware already in place . . . -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 14:35:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18635 for ; Tue, 29 Jan 2002 14:35:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA24892 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 14:35:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23002; Tue, 29 Jan 2002 14:03:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22966 for ; Tue, 29 Jan 2002 14:03:32 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16324 for ; Tue, 29 Jan 2002 14:03:29 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0TJ3Mb20900; Tue, 29 Jan 2002 13:03:22 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 13:03:22 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE59@VA02> From: "Peterson, Jon" To: "'Cullen Jennings'" , Michael Thomas , sip@ietf.org Date: Tue, 29 Jan 2002 13:03:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Summary of TLS discussion Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm afraid Mike's summary requires some small amount of clarification. There are essentially three proposals under discussion for the lower-layer security function. This lower-layer function should supply hop-by-hop data integrity and confidentiality, and possibly authentication. 1) TLS: Doesn't support UDP. Has an innate key exchange system. Use of TLS with an application like SIP is fairly straightforward. A minimum profile for authentication/integrity/encryption is provided in bis06 today. Opinions to the contrary notwithstanding, it can probably be implemented in less than 400K of code (a recent IEEE Comm's article claimed 100K). Then two IPSec proposals (no IPSec minimum profile is proposed in bis06 today), both of which will support UDP. 2) IPSec transport mode: Is integrated into the 'operating system' (in hosts that have one) and into applications - essentially, it plays a similar role to TLS (however, since IPSec is modular, it may or not may not instantiate any of TLS's functions), providing host by host security functions - which functions, exactly, depends on the profile. Some of the details of integrating this into applications may be complicated. 3) IPsec tunnel mode: Uses security gateways, and therefore is not integrated with applications. Essentially uses a VPN to secure SIP clients. This can be used opportunistically to secure any Internet applications today. Mike proposed a minimum profile for IPSec consisting of transport mode ESP without a means of exchanging keys (manual key exchange required) or a means of encrypting data, just a means of doing authentication and integrity. In other words, Mike's proposal does not provide a story for confidentiality. The ESP standard minimally requires support for DES. Mike asserts that his profile can be implemented in 6K of code. Brian Rosen then asked how many people liked Mike's profile. I posed the parallel question of who preferred transport mode to tunnel mode IPSec. I think both Brian and I are still interested to hear fresh opinions on these matters. Today, the normative text in bis06 strongly RECOMMENDS that UAs support TLS. Proxies, registrars, and redirect servers MUST support TLS. All SIP entities MAY support IPSec. UAs MUST support TCP and UDP. This arguments made in favor of TLS versus IPSec, roughly, have been: - Mike argues that TLS doesn't meet the requirements because it doesn't support UDP. Advocates of TLS argue that the requirement is actually to guarantee that every UA can speak securely to every proxy, not to mandate that they be able to do so over every transport protocol they support. - Mike feels strongly that the lack of centralized public key infrastructure in the real world means that key exchange is actually useless (in which case TLS's must-implement key exchange would be a liability, whereas IPSec modular approach would allow implementers to save some memory). TLS advocates argue that TLS for SIP will replicate the web model, in which clients verify the site certificates of servers (in the SIP world proxy servers and so forth), and that this is in fact quite real and quite widely deployed. - Another factor in the key exchange debacle is that IPSec key-exchange mechanisms tend to require two-way key exchange, and both sides of this argument agree that client-side certificates are an unsolved problem (neither TLS mutual authentication with certificates nor any IPSec mutual authentication is tractable). TLS advocates would argue that a client can authenticate itself to a server with some non-TLS method, like Digest. - Mike also dislikes X.509 certificates. TLS advocates fall back on their widespread use for e-commerce today. - TLS has a good NAT traversal story. On several fronts (enumerated in a draft by Bernand Aboba), IPSec does not. - Finally, there has been some talk about whether or not the proposed minimum profiles meet the requirements. Mike feels that an IPSec minimum profile should not have to specify a data encryption mechanism or key exchange mechanism. TLS advocates have argued that SIP requires these capabilities, and that TLS provides such mechanisms. That's pretty much it. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, January 29, 2002 9:56 AM > To: Michael Thomas; sip@ietf.org > Subject: RE: [Sip] TLS section > > > > Just to help everyone on the list that has not followed all > of this (Me if > no one else :-) Could you briefly summarize the 6k and 400k solution? > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > Behalf Of Michael > > Thomas > > Sent: Tuesday, January 29, 2002 8:41 AM > > To: Rosen, Brian > > Cc: 'Dean Willis'; Peterson, Jon; 'Michael Thomas'; sip@ietf.org > > Subject: RE: [Sip] TLS section > > > > > > Rosen, Brian writes: > > > I know this argument well; it's the "any security takes too much > > > cpu/memory". I don't buy it. > > > > In fact, the minimum requirement that I've been > > recommending can and has been implemented in 6000 > > bytes of code. Anybody who can't afford that can't > > afford *any* crypto whatsoever since 5kb of that > > was just for the hash. This can be done at app layer, > > the kernel, or as a bump in the stack. There is just > > no excuse at all not to at least do this; it should > > be a MUST. > > > > Yet, this very simple thing that could be done, widely > > implemented and deployed is being sent off into Siberia > > by the IESG in favor of something that requires 400kb > > of code, doesn't meet the basic requirements, and > > isn't even a MUST. > > > > This is insane. > > > > 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 > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 14:41:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18827 for ; Tue, 29 Jan 2002 14:41:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25220 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 14:41:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23625; Tue, 29 Jan 2002 14:19:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23600 for ; Tue, 29 Jan 2002 14:19:33 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17440 for ; Tue, 29 Jan 2002 14:19:30 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0TJJFb18382; Tue, 29 Jan 2002 14:19:15 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 13:19:15 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE5B@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" , Juha Heinanen Cc: "Rosen, Brian" , "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] TLS section Date: Tue, 29 Jan 2002 13:19:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Or maybe Juha would like TLS, because you don't have to do any manually keying. Note that e-commerce requires a global PKI, but only so servers can authenticate themselves to clients (via TLS). When a client authenticates itself to a server in the web, it uses HTTP Auth (i.e. Digest) to communicate a username and password to the server. This assymetry is exactly what we're proposing for SIP. Distributing keys to servers, and passwords to users, is not a fantasy - it is a hard reality, and we can re-use this for SIP. When you give up that global server-side PKI, you give up the ability for SIP to be used in arbitrary interdomain contexts, where clients speak securely to servers they've never addressed before. I think this would be a great loss for SIP, and I think we need it regardless of whether we choose TLS or IPSec. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, January 29, 2002 10:21 AM > To: Juha Heinanen > Cc: Michael Thomas; Rosen, Brian; 'Dean Willis'; Peterson, Jon; > sip@ietf.org > Subject: RE: [Sip] TLS section > > > Juha Heinanen writes: > > Michael Thomas writes: > > > > > > I know this argument well; it's the "any security > takes too much > > > > cpu/memory". I don't buy it. > > > > i don't care of cpu/memory, but i get mad if security makes > > configuration of the ua more difficult than what it is w/o > security or > > if sip phones can't be used without a global pki. so > whatever security > > technology is chosen, it MUST be based on self generated > keys so that > > username/password is the only thing that needs to be > configured in the > > ua for security. > > Then you should like my proposal. In fact, you could > use the exact same key that you use for digest, as well > as share the code for MD5. > > 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 daemon@optimus.ietf.org Tue Jan 29 14:42:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18847 for ; Tue, 29 Jan 2002 14:41:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA25241 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 14:42:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23706; Tue, 29 Jan 2002 14:21:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23675 for ; Tue, 29 Jan 2002 14:21:19 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17489 for ; Tue, 29 Jan 2002 14:21:12 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g0TJGiH01758; Tue, 29 Jan 2002 13:16:44 -0600 Message-Id: <200201291916.g0TJGiH01758@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: Michael Thomas , Juha Heinanen Subject: IPSEC with 3G mobiles idea (was Re: [Sip] TLS section) Date: Tue, 29 Jan 2002 13:16:42 -0600 X-Mailer: KMail [version 1.3.2] Cc: Michael Thomas , "Rosen, Brian" , "'Dean Willis'" , "Peterson, Jon" , sip@ietf.org References: <313680C9A886D511A06000204840E1CF57C85D@whq-msgusr-02.pit.comms.marconi.com> <15446.57035.913124.978379@harjus.eng.song.fi> <15446.59391.333686.165897@thomasm-u1.cisco.com> In-Reply-To: <15446.59391.333686.165897@thomasm-u1.cisco.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit On Tuesday 29 January 2002 12:20 pm, Michael Thomas wrote: > Juha Heinanen writes: > > Michael Thomas writes: > > > > I know this argument well; it's the "any security takes too > > > > much cpu/memory". I don't buy it. > > > > i don't care of cpu/memory, but i get mad if security makes > > configuration of the ua more difficult than what it is w/o > > security or if sip phones can't be used without a global pki. so > > whatever security technology is chosen, it MUST be based on self > > generated keys so that username/password is the only thing that > > needs to be configured in the ua for security. > > Then you should like my proposal. In fact, you could > use the exact same key that you use for digest, as well > as share the code for MD5. > > Mike Actually, this is a fairly clean approach, provided that the session key can be known to the first-hop porxy, The problem is, the key used for digest is generally known only to the UA and to the service point doing SIP authentication, and not to intermediate proxies including the first-hop proxy. So you need some key management. For the 3GPP model, it seems like it might be feasible to "dynamically" engage IPSEC between the mobile and the P-CSCF, using a session key derived from the key mechanism of the SIM card. Here's how it might work. Interproxy connections are covered by IPSEC ESP. The mobile-to-proxy connection is initially unprotected. The initial REGISTER is sent "in the clear". The authenticating node issues a 401, and attaches a session key and a nonce. This session key is protected back to the visited proxy by an IPSEC SA chain. The visited proxy strips the session key and hands it to the IPSEC layer. The mobile then uses the nonce and its smart card to generate a matching session key, which it then uses to set up an IPSEC SA with the visited proxy. So, we've now used the the AKA key mechanism to set up an SA to an intermediate proxy, without compromising any long-term secrets. But even this usage doesn't address the one-way relationship model allowed by TLS, and I think we'll have many requirements for that as well. I see no alternative besides allowing the systems implementor/operator to select from IPSEC, TLS, or something else as appropriate to the particular system's requirements. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Tue Jan 29 15:07:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19416 for ; Tue, 29 Jan 2002 15:07:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA26636 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 15:07:37 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24663; Tue, 29 Jan 2002 14:31:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24612 for ; Tue, 29 Jan 2002 14:31:18 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18466 for ; Tue, 29 Jan 2002 14:31:14 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0TJVFX4008010; Tue, 29 Jan 2002 20:31:15 +0100 (MET) Received: from lmf.ericsson.se (lmf05397pc.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0TJVDr6015753; Tue, 29 Jan 2002 21:31:14 +0200 (EET) Message-ID: <3C56F883.1E46E0BE@lmf.ericsson.se> Date: Tue, 29 Jan 2002 21:31:15 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Juha Heinanen , Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP References: <70565611B164D511957A001083FCDD56CAAE4C@VA02> <15445.60276.858845.659265@thomasm-u1.cisco.com> <15446.18188.392456.823741@harjus.eng.song.fi> <3C56D6A7.86BC5E9A@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I do understand the reasons for using TCP, but why does it have to be a "MUST"? My node may never send messages so big, and it may be used in a network where it will never receive messages such big. Also, there may be nodes which will always communicate with a specific outbound proxy, so they may use a "static" SCTP association for that. So, saying that nodes handling big messages shall use TCP (or similar) is ok, but making TCP mandatory for EVERY node is another issue... I also don't think we shall throw away UDP, and always use TCP, because, as Gonzalo said, in most cases UDP will be just fine. Regards, Christer Holmberg Ericsson Finland Gonzalo Camarillo wrote: > > Hi, > > UDP is still useful when you are sending small messages. If you want to > send large messages, use TCP. But if, by any chance, your message is > small, you can avoid the three way handshake by using UDP. I do not see > why because some (or many) applications will use large messages, the > rest of the applications that do not use them have to pay the price of > the 3-way handshake as well. > > Regards, > > Gonzalo > > Juha Heinanen wrote: > > > > Michael Thomas writes: > > > > > Frankly, I think this debate would be much better > > > served by talking about what the *real* > > > implication is here: deprecating UDP. Are you > > > and the rest of the authors ready to do that? > > > > i'm not an author, but a couple of weeks ago we had (and i guess still > > have) problems with udp fragmentation. now if udp would also require > > ipsec, then there is one more good argument to deprecate udp (as i > > already suggested in connection with the udp problems). > > > > -- 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 > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 29 15:29:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19975 for ; Tue, 29 Jan 2002 15:29:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA27583 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 15:29:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25888; Tue, 29 Jan 2002 14:59:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25857 for ; Tue, 29 Jan 2002 14:59:44 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19285 for ; Tue, 29 Jan 2002 14:59:40 -0500 (EST) Received: from harjus.eng.song.fi (harjus.eng.song.fi [195.10.149.20]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0TJtnio005315; Tue, 29 Jan 2002 21:55:50 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.65093.894734.460276@harjus.eng.song.fi> Date: Tue, 29 Jan 2002 21:55:49 +0200 To: "Peterson, Jon" Cc: "'Cullen Jennings'" , Michael Thomas , sip@ietf.org Subject: [Sip] Summary of TLS discussion In-Reply-To: <70565611B164D511957A001083FCDD56CAAE59@VA02> References: <70565611B164D511957A001083FCDD56CAAE59@VA02> X-Mailer: VM 7.00 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > - TLS has a good NAT traversal story. On several fronts (enumerated in a > draft by Bernand Aboba), IPSec does not. i forgot this one. since nats are nowadays everywhere, the security solution MUST have a good nat story. otherwise sip will be dead on arrival. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 29 15:32:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20072 for ; Tue, 29 Jan 2002 15:32:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA28054 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 15:32:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26462; Tue, 29 Jan 2002 15:03:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26428 for ; Tue, 29 Jan 2002 15:03:50 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19365 for ; Tue, 29 Jan 2002 15:03:46 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0TK3Bd01132; Tue, 29 Jan 2002 12:03:11 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT83086; Tue, 29 Jan 2002 12:02:39 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA21547; Tue, 29 Jan 2002 12:03:09 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15446.65533.591315.693326@thomasm-u1.cisco.com> Date: Tue, 29 Jan 2002 12:03:09 -0800 (PST) To: Juha Heinanen Cc: "Peterson, Jon" , "'Cullen Jennings'" , Michael Thomas , sip@ietf.org Subject: [Sip] Summary of TLS discussion In-Reply-To: <15446.65093.894734.460276@harjus.eng.song.fi> References: <70565611B164D511957A001083FCDD56CAAE59@VA02> <15446.65093.894734.460276@harjus.eng.song.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Juha Heinanen writes: > Peterson, Jon writes: > > > - TLS has a good NAT traversal story. On several fronts (enumerated in a > > draft by Bernand Aboba), IPSec does not. > > i forgot this one. since nats are nowadays everywhere, the security > solution MUST have a good nat story. otherwise sip will be dead on > arrival. IPsec working group is working on a standards track way of doing this. Basically, ESP over UDP. 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 daemon@ns.ietf.org Tue Jan 29 15:42:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20383 for ; Tue, 29 Jan 2002 15:42:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA28553 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 15:42:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26775; Tue, 29 Jan 2002 15:09:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26675 for ; Tue, 29 Jan 2002 15:08:57 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19460 for ; Tue, 29 Jan 2002 15:08:53 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GQP00F01UKI4S@firewall.wcom.com> for sip@ietf.org; Tue, 29 Jan 2002 20:07:30 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GQP00EK6UKH52@firewall.wcom.com>; Tue, 29 Jan 2002 20:07:30 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQP00F01UK75L@pmismtp03.wcomnet.com>; Tue, 29 Jan 2002 20:07:29 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GQP00CDBUJSDI@pmismtp03.wcomnet.com>; Tue, 29 Jan 2002 20:07:08 +0000 (GMT) Date: Tue, 29 Jan 2002 14:07:01 -0600 From: Henry Sinnreich Subject: RE: [Sip] bis-06 now available! In-reply-to: <17052388D394D411803900508BDFFAF601B37199@n0214idc1.oss.level3.com> To: John.Hearty@Level3.com, Mpierce1@aol.com, sip@ietf.org Message-id: <000401c1a900$87fec740$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >> I'll second that attaboy. Please add one more admirer for this excellent and tireless work! Henry Sinnreich WorldCom > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > John.Hearty@Level3.com > Sent: Tuesday, January 29, 2002 11:33 AM > To: Mpierce1@aol.com; sip@ietf.org > Subject: RE: [Sip] bis-06 now available! > > > Amazing work Jonathan and all. > > > > History of document size: > > RFC2543 331k bytes > > -02 381k bytes > > -04 449k bytes > > -05 510 k bytes > > -06 667k bytes > > > > (Largest RFC published to date - 585k bytes) > > > > Will we reach 1meg before the next SIP RFC is published? > > > > Mike > > > > I'll second that attaboy. Some would argue size doesn't matter ;-) but > the > content of this draft is excellent. I would like to thank each of the > authors for their tireless work improving this specification, plugging the > holes, and struggling to reach consensus with the many list participants. > Great job. > > John Hearty > Level3 > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 29 15:54:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20698 for ; Tue, 29 Jan 2002 15:54:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA29009 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 15:54:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27219; Tue, 29 Jan 2002 15:21:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27190 for ; Tue, 29 Jan 2002 15:21:30 -0500 (EST) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19721 for ; Tue, 29 Jan 2002 15:21:26 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GQP00001V6LKP@firewall.wcom.com> for sip@ietf.org; Tue, 29 Jan 2002 20:20:46 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GQP0007IV6L2L@firewall.wcom.com>; Tue, 29 Jan 2002 20:20:45 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQP00M01V6I1S@pmismtp03.wcomnet.com>; Tue, 29 Jan 2002 20:20:44 +0000 (GMT) Received: from hsinnreich2 ([166.35.224.250]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GQP00IGUV60DV@pmismtp03.wcomnet.com>; Tue, 29 Jan 2002 20:20:27 +0000 (GMT) Date: Tue, 29 Jan 2002 14:20:25 -0600 From: Henry Sinnreich Subject: RE: [Sip] Summary of TLS discussion In-reply-to: <15446.65093.894734.460276@harjus.eng.song.fi> To: "'Juha Heinanen'" , "'Peterson, Jon'" Cc: "'Cullen Jennings'" , "'Michael Thomas'" , sip@ietf.org Message-id: <001101c1a902$649e01b0$fae023a6@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There are good products that support NAT. Henry > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Juha > Heinanen > Sent: Tuesday, January 29, 2002 1:56 PM > To: Peterson, Jon > Cc: 'Cullen Jennings'; Michael Thomas; sip@ietf.org > Subject: [Sip] Summary of TLS discussion > > Peterson, Jon writes: > > > - TLS has a good NAT traversal story. On several fronts (enumerated in > a > > draft by Bernand Aboba), IPSec does not. > > i forgot this one. since nats are nowadays everywhere, the security > solution MUST have a good nat story. otherwise sip will be dead on > arrival. > > -- juha > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 29 16:10:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21101 for ; Tue, 29 Jan 2002 16:10:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29975 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 16:10:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28596; Tue, 29 Jan 2002 15:43:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28565 for ; Tue, 29 Jan 2002 15:43:12 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20398 for ; Tue, 29 Jan 2002 15:43:08 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0TKgYL06000; Tue, 29 Jan 2002 12:42:34 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT84142; Tue, 29 Jan 2002 12:42:04 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA21559; Tue, 29 Jan 2002 12:42:34 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15447.2362.202362.391339@thomasm-u1.cisco.com> Date: Tue, 29 Jan 2002 12:42:34 -0800 (PST) To: Dean Willis Cc: Michael Thomas , Dean Willis , "Peterson, Jon" , "'Rosen, Brian'" , sip@ietf.org Subject: Re: [Sip] TLS section In-Reply-To: <200201291850.g0TIo6H01594@bdsl.66.12.12.130.gte.net> References: <70565611B164D511957A001083FCDD56CAAE49@VA02> <200201291554.g0TFsCN09270@bdsl.66.12.12.130.gte.net> <15446.55503.822947.102040@thomasm-u1.cisco.com> <200201291850.g0TIo6H01594@bdsl.66.12.12.130.gte.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > Why force double-protection on links that already have a layer-2 > protection which has key-management in place to coordinate with > app-layer DIGEST? These mobile devices already have AKA software and in > many cases DES hardware already in place . . . L2 security protects L2. There's still plenty of attacks that you can mount even with L2 security. For example, even with BPI on DOCSIS cable, I could still spoof packets to the UA from somewhere else on the net to do annoying things. This is one of those "layers of defense is good" things, I think. 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 daemon@ns.ietf.org Tue Jan 29 16:13:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21162 for ; Tue, 29 Jan 2002 16:13:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA00108 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 16:13:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27265; Tue, 29 Jan 2002 15:21:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27234 for ; Tue, 29 Jan 2002 15:21:40 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19723 for ; Tue, 29 Jan 2002 15:21:36 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0TKL8L17133; Tue, 29 Jan 2002 12:21:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT83578; Tue, 29 Jan 2002 12:20:37 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA21550; Tue, 29 Jan 2002 12:21:07 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15447.1075.177706.142185@thomasm-u1.cisco.com> Date: Tue, 29 Jan 2002 12:21:07 -0800 (PST) To: "Peterson, Jon" Cc: "'Cullen Jennings'" , Michael Thomas , sip@ietf.org In-Reply-To: <70565611B164D511957A001083FCDD56CAAE59@VA02> References: <70565611B164D511957A001083FCDD56CAAE59@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Subject: [Sip] Summary of TLS discussion Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit A few minor clarifications: 1) I don't think that PKI's etc are useless. I'm just extremely suspicious of any argument which starts with "first we posit a global PKI..." 2) Confidentiality could obviously be included into my proposal. I'm pretty neutral here. 3) Making UDP a poor relation to TCP will guarantee that most if not all UDP-speaking UA's will be done in the clear. I don't find that acceptible. Security needs to be available for *all* available mechanisms, not just some. Either come up with a solution for UDP, or deprecate use of UDP altogether. Mike Peterson, Jon writes: > I'm afraid Mike's summary requires some small amount of clarification. There > are essentially three proposals under discussion for the lower-layer > security function. This lower-layer function should supply hop-by-hop data > integrity and confidentiality, and possibly authentication. > > 1) TLS: Doesn't support UDP. Has an innate key exchange system. Use of TLS > with an application like SIP is fairly straightforward. A minimum profile > for authentication/integrity/encryption is provided in bis06 today. Opinions > to the contrary notwithstanding, it can probably be implemented in less than > 400K of code (a recent IEEE Comm's article claimed 100K). > > Then two IPSec proposals (no IPSec minimum profile is proposed in bis06 > today), both of which will support UDP. > > 2) IPSec transport mode: Is integrated into the 'operating system' (in hosts > that have one) and into applications - essentially, it plays a similar role > to TLS (however, since IPSec is modular, it may or not may not instantiate > any of TLS's functions), providing host by host security functions - which > functions, exactly, depends on the profile. Some of the details of > integrating this into applications may be complicated. > 3) IPsec tunnel mode: Uses security gateways, and therefore is not > integrated with applications. Essentially uses a VPN to secure SIP clients. > This can be used opportunistically to secure any Internet applications > today. > > Mike proposed a minimum profile for IPSec consisting of transport mode ESP > without a means of exchanging keys (manual key exchange required) or a means > of encrypting data, just a means of doing authentication and integrity. In > other words, Mike's proposal does not provide a story for confidentiality. > The ESP standard minimally requires support for DES. Mike asserts that his > profile can be implemented in 6K of code. > > Brian Rosen then asked how many people liked Mike's profile. I posed the > parallel question of who preferred transport mode to tunnel mode IPSec. I > think both Brian and I are still interested to hear fresh opinions on these > matters. > > Today, the normative text in bis06 strongly RECOMMENDS that UAs support TLS. > Proxies, registrars, and redirect servers MUST support TLS. All SIP entities > MAY support IPSec. UAs MUST support TCP and UDP. > > This arguments made in favor of TLS versus IPSec, roughly, have been: > > - Mike argues that TLS doesn't meet the requirements because it doesn't > support UDP. Advocates of TLS argue that the requirement is actually to > guarantee that every UA can speak securely to every proxy, not to mandate > that they be able to do so over every transport protocol they support. > > - Mike feels strongly that the lack of centralized public key infrastructure > in the real world means that key exchange is actually useless (in which case > TLS's must-implement key exchange would be a liability, whereas IPSec > modular approach would allow implementers to save some memory). TLS > advocates argue that TLS for SIP will replicate the web model, in which > clients verify the site certificates of servers (in the SIP world proxy > servers and so forth), and that this is in fact quite real and quite widely > deployed. > > - Another factor in the key exchange debacle is that IPSec key-exchange > mechanisms tend to require two-way key exchange, and both sides of this > argument agree that client-side certificates are an unsolved problem > (neither TLS mutual authentication with certificates nor any IPSec mutual > authentication is tractable). TLS advocates would argue that a client can > authenticate itself to a server with some non-TLS method, like Digest. > > - Mike also dislikes X.509 certificates. TLS advocates fall back on their > widespread use for e-commerce today. > > - TLS has a good NAT traversal story. On several fronts (enumerated in a > draft by Bernand Aboba), IPSec does not. > > - Finally, there has been some talk about whether or not the proposed > minimum profiles meet the requirements. Mike feels that an IPSec minimum > profile should not have to specify a data encryption mechanism or key > exchange mechanism. TLS advocates have argued that SIP requires these > capabilities, and that TLS provides such mechanisms. > > That's pretty much it. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Tuesday, January 29, 2002 9:56 AM > > To: Michael Thomas; sip@ietf.org > > Subject: RE: [Sip] TLS section > > > > > > > > Just to help everyone on the list that has not followed all > > of this (Me if > > no one else :-) Could you briefly summarize the 6k and 400k solution? > > > > > > > -----Original Message----- > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > > Behalf Of Michael > > > Thomas > > > Sent: Tuesday, January 29, 2002 8:41 AM > > > To: Rosen, Brian > > > Cc: 'Dean Willis'; Peterson, Jon; 'Michael Thomas'; sip@ietf.org > > > Subject: RE: [Sip] TLS section > > > > > > > > > Rosen, Brian writes: > > > > I know this argument well; it's the "any security takes too much > > > > cpu/memory". I don't buy it. > > > > > > In fact, the minimum requirement that I've been > > > recommending can and has been implemented in 6000 > > > bytes of code. Anybody who can't afford that can't > > > afford *any* crypto whatsoever since 5kb of that > > > was just for the hash. This can be done at app layer, > > > the kernel, or as a bump in the stack. There is just > > > no excuse at all not to at least do this; it should > > > be a MUST. > > > > > > Yet, this very simple thing that could be done, widely > > > implemented and deployed is being sent off into Siberia > > > by the IESG in favor of something that requires 400kb > > > of code, doesn't meet the basic requirements, and > > > isn't even a MUST. > > > > > > This is insane. > > > > > > 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 > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 29 16:43:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21759 for ; Tue, 29 Jan 2002 16:43:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA01872 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 16:43:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00193; Tue, 29 Jan 2002 16:15:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00161 for ; Tue, 29 Jan 2002 16:14:58 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21182 for ; Tue, 29 Jan 2002 16:14:53 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g0TL99S13808; Tue, 29 Jan 2002 15:09:09 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g0TL99423287; Tue, 29 Jan 2002 15:09:09 -0600 (CST) Received: from lmf.ericsson.se (rmt160122.am.ericsson.se [138.85.160.122]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA27284; Tue, 29 Jan 2002 15:09:07 -0600 (CST) Message-ID: <3C571685.53F45592@lmf.ericsson.se> Date: Tue, 29 Jan 2002 23:39:17 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "Peterson, Jon" , "'Cullen Jennings'" , sip@ietf.org Subject: Re: [Sip] Summary of TLS discussion References: <70565611B164D511957A001083FCDD56CAAE59@VA02> <15447.1075.177706.142185@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, > 3) Making UDP a poor relation to TCP will guarantee > that most if not all UDP-speaking UA's will be > done in the clear. I don't find that acceptible. > Security needs to be available for *all* available > mechanisms, not just some. Either come up with a > solution for UDP, or deprecate use of UDP altogether. > I disagree with this statement. If you want to have a secure SIP transaction, you will be willing to accept the TCP 3-way handshake plus the 2 RTTs to establish a TLS connection. However, if you do not need security for this particular transaction, you can avoid all these RTTs by using UDP. Therefore, you can see UDP as an optimization for systems that do not want security at a certain point of time. And I believe that having UDP in the protocol is a valuable optimization. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 29 16:55:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22033 for ; Tue, 29 Jan 2002 16:55:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA02340 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 16:55:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00647; Tue, 29 Jan 2002 16:26:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00618 for ; Tue, 29 Jan 2002 16:26:57 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21362 for ; Tue, 29 Jan 2002 16:26:52 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0TLQNI17555; Tue, 29 Jan 2002 13:26:23 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT85197; Tue, 29 Jan 2002 13:25:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA21573; Tue, 29 Jan 2002 13:26:22 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15447.4990.586456.670164@thomasm-u1.cisco.com> Date: Tue, 29 Jan 2002 13:26:22 -0800 (PST) To: Gonzalo Camarillo Cc: Michael Thomas , "Peterson, Jon" , "'Cullen Jennings'" , sip@ietf.org Subject: Re: [Sip] Summary of TLS discussion In-Reply-To: <3C571685.53F45592@lmf.ericsson.se> References: <70565611B164D511957A001083FCDD56CAAE59@VA02> <15447.1075.177706.142185@thomasm-u1.cisco.com> <3C571685.53F45592@lmf.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo writes: > I disagree with this statement. If you want to have a secure SIP > transaction, you will be willing to accept the TCP 3-way handshake plus > the 2 RTTs to establish a TLS connection. However, if you do not need > security for this particular transaction, you can avoid all these RTTs > by using UDP. Why does it follow that I'd be willing to incure TCP overhead just because I want security? Secure DNS certainly doesn't make any such assumption. What I really want is the fewest possible messages to get the job done. > Therefore, you can see UDP as an optimization for systems that do not > want security at a certain point of time. In other words, UDP is a poor relation. 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 daemon@ns.ietf.org Tue Jan 29 17:05:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22391 for ; Tue, 29 Jan 2002 17:05:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03397 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 17:05:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01659; Tue, 29 Jan 2002 16:39:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01628 for ; Tue, 29 Jan 2002 16:38:58 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21674 for ; Tue, 29 Jan 2002 16:38:53 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0TLcPI26569 for ; Tue, 29 Jan 2002 13:38:25 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT85535; Tue, 29 Jan 2002 13:37:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA21581; Tue, 29 Jan 2002 13:38:25 -0800 (PST) Date: Tue, 29 Jan 2002 13:38:25 -0800 (PST) Message-Id: <200201292138.NAA21581@thomasm-u1.cisco.com> From: Michael Thomas To: sip@ietf.org X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Subject: [Sip] one more 3G consideration Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org As far as I've last heard, 3G is requiring IPv6. IPv6 requires IPsec (rfc 2460, security considerations). 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 daemon@ns.ietf.org Tue Jan 29 17:15:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22639 for ; Tue, 29 Jan 2002 17:15:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03750 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 17:15:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02158; Tue, 29 Jan 2002 16:49:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02133 for ; Tue, 29 Jan 2002 16:49:31 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21897 for ; Tue, 29 Jan 2002 16:49:26 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0TLnQh07691; Tue, 29 Jan 2002 15:49:26 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g0TLnPC18773; Tue, 29 Jan 2002 15:49:25 -0600 (CST) Received: from lmf.ericsson.se (rmt160122.am.ericsson.se [138.85.160.122]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA01253; Tue, 29 Jan 2002 15:49:23 -0600 (CST) Message-ID: <3C571FF6.AA14394B@lmf.ericsson.se> Date: Wed, 30 Jan 2002 00:19:34 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "Peterson, Jon" , "'Cullen Jennings'" , sip@ietf.org Subject: Re: [Sip] Summary of TLS discussion References: <70565611B164D511957A001083FCDD56CAAE59@VA02> <15447.1075.177706.142185@thomasm-u1.cisco.com> <3C571685.53F45592@lmf.ericsson.se> <15447.4990.586456.670164@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Michael Thomas wrote: > What I really want is > the fewest possible messages to get the job > done. We have two scenarios: 1) we want security for this SIP transaction 2) we do not want security for this SIP transaction If we do not want security for a particular transaction, "the minimum number of messages to get the job done" is achieved using UDP. That's why I believe that deprecating UDP is out of the question. If we want security, that's another story, and that's what we are discussing in this thread. Regards, Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 29 17:16:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22689 for ; Tue, 29 Jan 2002 17:16:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03786 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 17:16:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01763; Tue, 29 Jan 2002 16:41:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01738 for ; Tue, 29 Jan 2002 16:41:01 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21715 for ; Tue, 29 Jan 2002 16:40:56 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g0TLeLH02720; Tue, 29 Jan 2002 15:40:21 -0600 Message-Id: <200201292140.g0TLeLH02720@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: Michael Thomas Subject: Re: [Sip] TLS section Date: Tue, 29 Jan 2002 15:40:17 -0600 X-Mailer: KMail [version 1.3.2] Cc: Michael Thomas , Dean Willis , "Peterson, Jon" , "'Rosen, Brian'" , sip@ietf.org References: <70565611B164D511957A001083FCDD56CAAE49@VA02> <200201291850.g0TIo6H01594@bdsl.66.12.12.130.gte.net> <15447.2362.202362.391339@thomasm-u1.cisco.com> In-Reply-To: <15447.2362.202362.391339@thomasm-u1.cisco.com> Organization: dynamicsoft Inc. MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Bogus. It just gives you another layer with the same threat model. I'll try and illustrate. Remember that we have hop-by-hop protection specified. Take example: |--S1----UA2 UA1-----------P1----------| |- S2----UA3 where UA2 and UA3 are on the same remote subnet. UA1 engages in call with UA2. The path here is UA1-P1-S1-UA2. Tunnel AH SAs include UA1<->P1, P1<->S1, P1<->S2, S1<->UA1, and S2<->UA3 S1 and S2 are stateless. UA3 deduces the vitals of the UA1-UA2 session (To, From, CallID) and spoofs a BYE. The BYE traverse know SAs UA33->S2, S2->P1, and P1->UA1, thereby taking the call down. UA2's source IP address is discoverable, but the attack succeeds. Now put UA2 and UA3 on the same subnet. UA3 can now spoof the source address of UA2. Since we're in tunnel mode, S1 accepts and forwards, and the attack continues. Transport mode IPSEC or TLS would have blocked it, however, as they institute a reverse-path-forwarding check to the singularsource address specified in the SA establishment. The first attack can be introduced wherever the SA is "transparent" to the SIP-level identity of the remote node. The second attack is blocked wherever the transport protection provides node identification and path verification, such as reverse-path-forwarding checks. The 3GPP L2 mechanism actually has some L3 hooks. Each PDP context, in addition to being integrity keyed (and optionally privacy keyed) has an associated address-set in the GGSN. This rejects address-spoofed packets originated from the mobile. If we assume that the network between P1 and GGSN is secure, we can preclude the unlikely event of spoofed packets being inserted at this layer. As a consequence, we get exactly the same protection behavior for UA1 using IPSEC Transport AH/ESP and using layer 2 AKA. The both defend from the same attacks, and fall to the same attacks. But as it turns out, most of the protection actually comes in at layer 4. Spoofing requires the presentation of conflicting identity information at different layers. Since the 3GPP service proxy "knows" the set of identities possible at UA1 and ties the AKA SA to the layer 4 identity presented (transitively thru control of AKA keying used by P1), S1 is effectively prevented from spoofing attacks within the 3G network. It can be readily shown that any link protection which does not bind identities across layers 2, 3, and 4 can be spoofed. The strength of the AKA mechanism here is not an inherent feature of AKA, it derives because we use associated keying across multiple layers. One could reproduce this by using IPSEC transport mode (with reverse-path checking) anddigest authentication, but only if some intermediary mechanism enforces the association between the IPSEC identity and the SIP identity. As Michael has demonstrated, the API to do this with IPSEC is not well-defined. The point of all this is that, barring underlying crypto-weakness, the 3GPP AKA model provides operational security at least as good as, and potentially significantly better than (due to cross-layer integration) IPSEC Transport AH when used between the mobile and the first-hop proxy. Therefore iit would appear to be absolutely pointless to use both AKA and IPSEC on this link. -- Dean On Tuesday 29 January 2002 02:42 pm, Michael Thomas wrote: > Dean Willis writes: > > Why force double-protection on links that already have a layer-2 > > protection which has key-management in place to coordinate with > > app-layer DIGEST? These mobile devices already have AKA software > > and in many cases DES hardware already in place . . . > > L2 security protects L2. There's still plenty of > attacks that you can mount even with L2 security. > For example, even with BPI on DOCSIS cable, I could > still spoof packets to the UA from somewhere else > on the net to do annoying things. This is one > of those "layers of defense is good" things, I > think. > > 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 daemon@ns.ietf.org Tue Jan 29 17:19:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22791 for ; Tue, 29 Jan 2002 17:19:03 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03873 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 17:19:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02273; Tue, 29 Jan 2002 16:52:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02242 for ; Tue, 29 Jan 2002 16:52:41 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21981 for ; Tue, 29 Jan 2002 16:52:36 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0TLq1d00104; Tue, 29 Jan 2002 13:52:01 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT85894; Tue, 29 Jan 2002 13:51:28 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA21584; Tue, 29 Jan 2002 13:51:58 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15447.6526.267208.192434@thomasm-u1.cisco.com> Date: Tue, 29 Jan 2002 13:51:58 -0800 (PST) To: Dean Willis Cc: Michael Thomas , Dean Willis , "Peterson, Jon" , "'Rosen, Brian'" , sip@ietf.org Subject: Re: [Sip] TLS section In-Reply-To: <200201292140.g0TLeLH02720@bdsl.66.12.12.130.gte.net> References: <70565611B164D511957A001083FCDD56CAAE49@VA02> <200201291850.g0TIo6H01594@bdsl.66.12.12.130.gte.net> <15447.2362.202362.391339@thomasm-u1.cisco.com> <200201292140.g0TLeLH02720@bdsl.66.12.12.130.gte.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean, I don't think I said that it was never redundant, and I'm sure you can find cases where it is. We need to consider the larger problem where L2 security (or lack thereof) is not an option. I'm sure that everybody's clued in to the 802.11 WEP mess, and I've heard tell that most cable MSO's don't bother turning on DOCSIS BPI (encryption). As I said, layering is a generally good thing, because it decreases your vulnerability to broken protocols and lazy operators. Mike Dean Willis writes: > > Bogus. It just gives you another layer with the same threat model. > > I'll try and illustrate. > > Remember that we have hop-by-hop protection specified. > > Take example: > |--S1----UA2 > UA1-----------P1----------| > |- S2----UA3 > > where UA2 and UA3 are on the same remote subnet. > > UA1 engages in call with UA2. > The path here is UA1-P1-S1-UA2. > > Tunnel AH SAs include UA1<->P1, P1<->S1, P1<->S2, S1<->UA1, and > S2<->UA3 > > S1 and S2 are stateless. > > UA3 deduces the vitals of the UA1-UA2 session (To, From, CallID) and > spoofs a BYE. The BYE traverse know SAs UA33->S2, S2->P1, and P1->UA1, > thereby taking the call down. UA2's source IP address is discoverable, > but the attack succeeds. > > Now put UA2 and UA3 on the same subnet. UA3 can now spoof the source > address of UA2. Since we're in tunnel mode, S1 accepts and forwards, > and the attack continues. Transport mode IPSEC or TLS would have > blocked it, however, as they institute a reverse-path-forwarding check > to the singularsource address specified in the SA establishment. > > The first attack can be introduced wherever the SA is "transparent" to > the SIP-level identity of the remote node. The second attack is blocked > wherever the transport protection provides node identification and path > verification, such as reverse-path-forwarding checks. > > The 3GPP L2 mechanism actually has some L3 hooks. Each PDP context, in > addition to being integrity keyed (and optionally privacy keyed) has an > associated address-set in the GGSN. This rejects address-spoofed > packets originated from the mobile. If we assume that the network > between P1 and GGSN is secure, we can preclude the unlikely event of > spoofed packets being inserted at this layer. > > As a consequence, we get exactly the same protection behavior for UA1 > using IPSEC Transport AH/ESP and using layer 2 AKA. The both defend > from the same attacks, and fall to the same attacks. > > But as it turns out, most of the protection actually comes in at layer > 4. Spoofing requires the presentation of conflicting identity > information at different layers. Since the 3GPP service proxy "knows" > the set of identities possible at UA1 and ties the AKA SA to the layer > 4 identity presented (transitively thru control of AKA keying used by > P1), S1 is effectively prevented from spoofing attacks within the 3G > network. > > It can be readily shown that any link protection which does not bind > identities across layers 2, 3, and 4 can be spoofed. > > The strength of the AKA mechanism here is not an inherent feature of > AKA, it derives because we use associated keying across multiple > layers. One could reproduce this by using IPSEC transport mode (with > reverse-path checking) anddigest authentication, but only if some > intermediary mechanism enforces the association between the IPSEC > identity and the SIP identity. As Michael has demonstrated, the API to > do this with IPSEC is not well-defined. > > The point of all this is that, barring underlying crypto-weakness, the > 3GPP AKA model provides operational security at least as good as, and > potentially significantly better than (due to cross-layer integration) > IPSEC Transport AH when used between the mobile and the first-hop proxy. > > Therefore iit would appear to be absolutely pointless to use both AKA > and IPSEC on this link. > > -- > Dean > > > > On Tuesday 29 January 2002 02:42 pm, Michael Thomas wrote: > > Dean Willis writes: > > > Why force double-protection on links that already have a layer-2 > > > protection which has key-management in place to coordinate with > > > app-layer DIGEST? These mobile devices already have AKA software > > > and in many cases DES hardware already in place . . . > > > > L2 security protects L2. There's still plenty of > > attacks that you can mount even with L2 security. > > For example, even with BPI on DOCSIS cable, I could > > still spoof packets to the UA from somewhere else > > on the net to do annoying things. This is one > > of those "layers of defense is good" things, I > > think. > > > > 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 daemon@ns.ietf.org Tue Jan 29 17:32:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23163 for ; Tue, 29 Jan 2002 17:32:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA04799 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 17:32:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03341; Tue, 29 Jan 2002 17:04:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03313 for ; Tue, 29 Jan 2002 17:04:14 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22375 for ; Tue, 29 Jan 2002 17:04:09 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0TM3gL19046 for ; Tue, 29 Jan 2002 14:03:42 -0800 (PST) Received: from cj14 (ssh-sj1.cisco.com [171.68.225.134]) by mira-sjc5-9.cisco.com (Mirapoint) with SMTP id ABX45307; Tue, 29 Jan 2002 14:03:52 -0800 (PST) From: "Cullen Jennings" To: Date: Tue, 29 Jan 2002 14:04:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Security with TCP, UDP, and ... Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Imagine we decide to run SIP on some new transport - hypothetically, lets say SCTP since it seems like there might be many good reasons for using it. Would that change how people want to do security? Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 29 18:24:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24177 for ; Tue, 29 Jan 2002 18:24:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA07192 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 18:24:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05460; Tue, 29 Jan 2002 17:53:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05351 for ; Tue, 29 Jan 2002 17:53:44 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23642 for ; Tue, 29 Jan 2002 17:53:40 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g0TMrDH03185; Tue, 29 Jan 2002 16:53:13 -0600 Message-Id: <200201292253.g0TMrDH03185@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-15" From: Dean Willis To: sip@ietf.org, wtm@research.att.com, Flemming Andreasen Date: Tue, 29 Jan 2002 16:53:10 -0600 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] Discussion of draft-ietf-sip-privacy-03 issues. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit draft-ietf-sip-privacy-03 does several notable things. 1) It defines a Remote-Party-ID header, which provides a way to state the identity of participants in a dialog, as well as describe some things about that identity, such directionality and its stutus as a device or human identity. 2) It provides the RPID-privacy header, which allows the end node to describe the privacy policy it wishes to have applied to any Remote-Party-ID headers added by intermediate nodes. 3) It provides an "Anonymity" header, which may requests some intermediate node to route the dialog via an "anonimyzer", essentially a trusted B2BUA that provides additional privacy protections for the requesting node. Let me start with #3, the "Anonymity" header. This appears to be the request for a specific routing service or feature which may or may not be available in a given network. I think some generalization of the expression is appropriate, and it may be worthwhile considering such alternatives as making this into a request parameter or as a specific service such as that targedted in RFC 2084. In general, I propose that the "Anonymity" header be extracted from this document and taken into a seperate body of work. #1 and #2, the Remote-Party-ID (RPID) header, and "RPID-Privacy" are deeply intertwingled. There is an implicit assumption in the draft that "the network" is a monolithic entity with a relatively homogenous trust fabric. This is consistent with the draft's stated goal of providing "NETWORK authenticated RPID", as opposed to RPIDs asserted by other parties, or by specific networks. There are a couple of things that the RPID syntax as drafted does not do that may be worthwhile to consider. 1) Informing us as to WHO has asserted the given RPID. The draft allows either the user, the terminal or "the network" to assert an RPID, but gives no indication as to which element has made the assertion. It might be useful to know which user, which network element, or even "which network" asserted the RPID. Such an identification may also be useful in selecting a decryption key, should the option of protecting the privacy by encrypting the asserted identity be exercised. 2) Informing us at to WHEN each assertion of RPID was made. This is a critical aspect for considering replay attacks, as a "stale" assertion seems more likley to be false. Of couse there are issues of absolute time and clock synchronization to consider, but there are discussions of using the RPID as a identity "ticket" for (ala Kerberos), and the value of time-awareness in ticket environments is well-understood. One might consider seprately the utility of indicating a duration for the assertion in relative-time terms. 3) Informing us as to the dialog-context in whch the assertion of identity is being made. Common SIP usage identifies the session-context as consisting of the tuple of To:, From:, and Call-ID: headers. Without this context, we have no way of knowing if the dialog has undergone a "retargeting" transformation since the identity was asserted. As drafted, we can assume that the assertion was made in the current dialog-context, but we have no way to verify that assumption and must relay on transitive trust back to the currently unidentfied asserting party. 4) Allowing us to verify, or authenticate, each assertion of RPID. It seems desirable to provide an authentication-token for each RPID which provides the ability to match the asserted RPID with the asserting identity, the time of the assertion, and the context of the assertion. One migh propose to achieve this by hashing the conetxt (To:, From, Call-ID) together with the asserting identity and the time of theassertion, using either a secret or public key associated with the asserting identity. It has been previously pointed out (MAT) that a verification token such as that proposed above (#4) is subject to replay. Specifically, it is possible for a party in possession of an RPID assertion to replay it for the same combination of context-determining parameters (To, From, Call-ID). It may be noted that time-bounding the assertion (as in #2 above) mitigates this problem to some extent, while adding the requirement for some general synchronization of clocks in order to provide this protection. On the other hand, it can be countered that the utility of such a mechanism, while imperfect, is significantly better than the warm but vacuous feeling one might get from implementing the orginal proposal. So, other than pretending I've been reading too much Dumas, I would like to poll the list for relevant suggestions. Should we adopt any or all of the four specific requirements given herein (asserting identity, time of assertion, context of assertion, and verification of assertion) into the RPID work? Should we also move the "Anonymity" header into a seperate draft as suggested? Thanks, -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 29 21:14:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26872 for ; Tue, 29 Jan 2002 21:14:43 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14325 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 21:14:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12978; Tue, 29 Jan 2002 20:51:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA12948 for ; Tue, 29 Jan 2002 20:51:19 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26651 for ; Tue, 29 Jan 2002 20:51:16 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0U1omd29521 for ; Tue, 29 Jan 2002 17:50:48 -0800 (PST) Received: from dhcp-128-107-141-67.cisco.com (dhcp-128-107-141-67.cisco.com [128.107.141.67]) by imop.cisco.com (Mirapoint) with ESMTP id ACK31567; Tue, 29 Jan 2002 17:50:47 -0800 (PST) Date: Tue, 29 Jan 2002 17:50:04 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] TLS vs IPsec Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Folks, Some additional comments for the lively TLS vs IPsec debate. Currently in bis-06 IPsec is a MAY, and TLS is a RECOMMENDED. Since neither of these are a MUST or even a SHOULD, implementations which want security should be free to pick an appropriate mechanism. World A: I envision that realistically TLS will be used by computing devices that have a general purpose web browser and a general purpose UI. These devices already need TLS and the associated PKI certificate code for web commerce, and have enough memory and ergs to do this. Because Proxys MUST implement TLS, these devices can talk to ANY proxy. World B: Some embedded SIP UAs (ex: mobile phones, cable modems with embedded gateways) will have a completely legitimate desire to use IPsec. Many of these devices will use IPv6 which requires IPsec anyway. There is also a good chance that these boxes already have something like a SIM card which contains a shared-secret key. These boxes are probably running IPv6 because there are supposed to be LOTS of them--therefore their manufacturer probably wants them to be cheap. This probably means they have very little RAM. They may also be using a scarce or specialized Layer2 resource, so bandwidth and/or latency on this interface is an issue. Therefore using UDP when the messages are small (they are incented to keep them small remember) is desirable. If these devices are using IPv6, it is unlikely that there will be a NAT between the UA and its first-hop proxy. By way of their SIM card, these devices are probably pre-configured to use a specific set of first-hop proxies that are known to support IPsec. Interoperability between Worlds: Now, for interoperability purposes, lets say that both Alice and Bob implemented TLS on their UAs. If Alice attempts to open a TLS connection directly with Bob, their is a good chance that neither Alice nor Bob have a "real" certificate. If they both have self-signed certificates, Bob would hopefully reject Alice's INVITE, possibly with a 305 Use Proxy response. If Alice goes through Bob's proxy, everything should work fine. If Alice wants to communicate with Cathy (who only implemented IPsec), she also has to go through Cathy's proxy, but everything still interoperates fine, because Cathy's proxy supports TLS (with Alice), and IPsec (with Cathy). I think Jon is an advocate for "World A" and Mike an advocate for "World B". Realistically both these worlds will exist, and should interoperate. We cannot and should not force fit one world into another (I'm not accusing anyone here :-). So what should we do? I personally think the text in bis-06 is pretty reasonable. I think we can accomodate both worlds with very minor changes in normative language. The one thing we do need IMO is an IPsec profile for SIP included as a peer to the TLS behavior. I'd like to encourage the IPsec proponents like Jari and Mike to whack on the IPsec profile this week (I know that Mike has already started on this). So.. if I had to fudge something now what would be my proposed new recommendations? Probably something like this... SIP User Agents SHOULD implement a standard message integrity mechanism (either TLS or IPsec as described later in this document). It is RECOMMENDED that SIP User Agents implement a standard message encryption mechanism (either TLS or IPsec as described later in this document). SIP User Agents which are designed for general purpose use on the Internet at large SHOULD use TLS. SIP User Agents designed for use in private networks MAY use either TLS or IPsec. SIP Proxy Servers used in private networks MUST support TLS *and* whatever the User Agents use. I also think we need a strong set of recommendations for SIP devices implementing IPsec to parallel the TLS recommendations. For example.... SIP User Agents which implement IPsec MUST support at least ESP authentication with for message integrity, and SHOULD support at least ESP with for confidentiality. UAs MUST? support transport mode and MAY? support tunnel mode. UAs MAY use any keying mechanism, for example shared-keys or IKE. UAs MAY use self-signed certs or purpose-built keys for client authentication. SIP Proxies which implement IPsec MUST support both transport and tunnel mode ESP with x, y, and z. Proxies MUST implement IKE but MAY use shared-keys or other keying mechanisms.... I hope this is useful. 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 daemon@ns.ietf.org Tue Jan 29 21:20:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26969 for ; Tue, 29 Jan 2002 21:20:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA14508 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 21:20:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13833; Tue, 29 Jan 2002 21:02:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13805 for ; Tue, 29 Jan 2002 21:02:20 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26769 for ; Tue, 29 Jan 2002 21:02:17 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0U21nd06376 for ; Tue, 29 Jan 2002 18:01:49 -0800 (PST) Received: from dhcp-128-107-141-67.cisco.com (dhcp-128-107-141-67.cisco.com [128.107.141.67]) by imop.cisco.com (Mirapoint) with ESMTP id ACK31660; Tue, 29 Jan 2002 18:01:49 -0800 (PST) Date: Tue, 29 Jan 2002 18:01:06 -0800 (Pacific Standard Time) From: Rohan Mahy To: sip@ietf.org Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Sip] ambiguities with S/MIME Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, In discussions with various folks about S/MIME, I think the current text on S/MIME is a great first start, but still too ambigous to build a robust implementation. Also I'm concerned that nobody has implemented this yet. I think splitting this out until we have a few interoperable implementations and have tested this at SIPit is a good thing. example ambiguities: it might be useful (especially with forking) to send the same message/sip signed with various certs that all correspond to me. how a UA would handle multiple message/sip bodies is unclear. if I can replace the "outer" To and From headers, which tags do I use in a Replaces header? If I receive an authenticated reINVITE in the clear which operates on the "inside" To/From/Callid/tags, is this valid? obviously some headers shouldn't get replaced: Via, Route, Record-Route are there any more? thoughts? 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 daemon@ns.ietf.org Tue Jan 29 21:39:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28176 for ; Tue, 29 Jan 2002 21:39:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA15557 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 21:39:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14551; Tue, 29 Jan 2002 21:20:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14520 for ; Tue, 29 Jan 2002 21:20:16 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26965 for ; Tue, 29 Jan 2002 21:20:06 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA16867; Tue, 29 Jan 2002 21:19:58 -0500 (EST) Received: from cs.columbia.edu (pool-138-89-41-181.mad.east.verizon.net [138.89.41.181]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0U2JfJ2029479 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 29 Jan 2002 21:19:52 -0500 (EST) Message-ID: <3C575999.F4034ECB@cs.columbia.edu> Date: Tue, 29 Jan 2002 21:25:29 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: sip@ietf.org Subject: Re: [Sip] TLS vs IPsec References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Hi Folks, > > Some additional comments for the lively TLS vs IPsec debate. > > Currently in bis-06 IPsec is a MAY, and TLS is a RECOMMENDED. Since > neither of these are a MUST or even a SHOULD, implementations which want > security should be free to pick an appropriate mechanism. Not quite. According to RFC 2119, RECOMMENDED is the same strength as SHOULD. "3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Tue Jan 29 22:12:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28596 for ; Tue, 29 Jan 2002 22:12:49 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA16803 for sip-archive@odin.ietf.org; Tue, 29 Jan 2002 22:12:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15946; Tue, 29 Jan 2002 21:51:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15915 for ; Tue, 29 Jan 2002 21:51:19 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28330 for ; Tue, 29 Jan 2002 21:51:15 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0U2ofd01822; Tue, 29 Jan 2002 18:50:41 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT93593; Tue, 29 Jan 2002 18:50:10 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA21632; Tue, 29 Jan 2002 18:50:40 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15447.24448.518014.473679@thomasm-u1.cisco.com> Date: Tue, 29 Jan 2002 18:50:40 -0800 (PST) To: Dean Willis Cc: Michael Thomas , Juha Heinanen , "Rosen, Brian" , "'Dean Willis'" , "Peterson, Jon" , sip@ietf.org Subject: IPSEC with 3G mobiles idea (was Re: [Sip] TLS section) In-Reply-To: <200201291916.g0TJGiH01758@bdsl.66.12.12.130.gte.net> References: <313680C9A886D511A06000204840E1CF57C85D@whq-msgusr-02.pit.comms.marconi.com> <15446.57035.913124.978379@harjus.eng.song.fi> <15446.59391.333686.165897@thomasm-u1.cisco.com> <200201291916.g0TJGiH01758@bdsl.66.12.12.130.gte.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean, I'm having a hard time believing that I'm actually writing this, but you might also consider looking at the mobile IP AAA keys drafts. Essentially they have a similar problem but want to leverage AAA based keys (eg, SIM based probably) to make a mobile node/home agent/foreign agent security associations. I'm not a huge fan of this work, but the considerations you describe seem pretty similar. Mike Dean Willis writes: > On Tuesday 29 January 2002 12:20 pm, Michael Thomas wrote: > > Juha Heinanen writes: > > > Michael Thomas writes: > > > > > I know this argument well; it's the "any security takes too > > > > > much cpu/memory". I don't buy it. > > > > > > i don't care of cpu/memory, but i get mad if security makes > > > configuration of the ua more difficult than what it is w/o > > > security or if sip phones can't be used without a global pki. so > > > whatever security technology is chosen, it MUST be based on self > > > generated keys so that username/password is the only thing that > > > needs to be configured in the ua for security. > > > > Then you should like my proposal. In fact, you could > > use the exact same key that you use for digest, as well > > as share the code for MD5. > > > > Mike > > Actually, this is a fairly clean approach, provided that the session > key can be known to the first-hop porxy, The problem is, the key used > for digest is generally known only to the UA and to the service point > doing SIP authentication, and not to intermediate proxies including the > first-hop proxy. So you need some key management. > > For the 3GPP model, it seems like it might be feasible to > "dynamically" engage IPSEC between the mobile and the P-CSCF, using a > session key derived from the key mechanism of the SIM card. > > Here's how it might work. Interproxy connections are covered by IPSEC > ESP. The mobile-to-proxy connection is initially unprotected. The > initial REGISTER is sent "in the clear". The authenticating node issues > a 401, and attaches a session key and a nonce. This session key is > protected back to the visited proxy by an IPSEC SA chain. The visited > proxy strips the session key and hands it to the IPSEC layer. The > mobile then uses the nonce and its smart card to generate a matching > session key, which it then uses to set up an IPSEC SA with the visited > proxy. So, we've now used the the AKA key mechanism to set up an SA to > an intermediate proxy, without compromising any long-term secrets. > > But even this usage doesn't address the one-way relationship model > allowed by TLS, and I think we'll have many requirements for that as > well. > > I see no alternative besides allowing the systems implementor/operator > to select from IPSEC, TLS, or something else as appropriate to the > particular system's requirements. > > -- > Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 30 00:24:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01863 for ; Wed, 30 Jan 2002 00:24:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA22644 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 00:24:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20587; Tue, 29 Jan 2002 23:33:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20556 for ; Tue, 29 Jan 2002 23:33:00 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01229 for ; Tue, 29 Jan 2002 23:32:55 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0U4Wub28201; Tue, 29 Jan 2002 23:32:56 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 22:32:56 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE64@VA02> From: "Peterson, Jon" To: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] TLS vs IPsec Date: Tue, 29 Jan 2002 22:32:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is really very useful; there are certainly multiple architectures that motivate our security positions. The focus on interoperability between TLS-based and IPSec-based services is also interesting - I don't think we've yet plumbed that space for requirements. That might warrant an I-D in and of itself down the road. ;) I agree that the SIP community needs to settle on a minimal IPSec profile. As we saw during the email thread yesterday, however, this might be more complicated than we initially surmised. I would suggest that this IPSec profile be explored in a separate I-D, possibly in the context of the SIP security design team. Your note seems to have a good start on a profile. I do have one additional comment below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rohan Mahy [mailto:rmahy@cisco.com] > Sent: Tuesday, January 29, 2002 5:50 PM > To: sip@ietf.org > Subject: [Sip] TLS vs IPsec > [snip] > > SIP User Agents which are designed for general purpose use on the > Internet at large SHOULD use TLS. SIP User Agents designed for use in > private networks MAY use either TLS or IPsec. SIP Proxy > Servers used in > private networks MUST support TLS *and* whatever the User Agents use. > Implementers may not know how a device they build will be used. I think that, unfortunately, vendors are on the hook to implement more things than any individual service provider is likely to deploy. The prerogative of the IETF, I think, is mostly to suggest what one must implement. > [snip] > 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 daemon@ns.ietf.org Wed Jan 30 00:49:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02531 for ; Wed, 30 Jan 2002 00:49:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA23567 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 00:49:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA22560; Wed, 30 Jan 2002 00:19:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA22531 for ; Wed, 30 Jan 2002 00:19:35 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01807 for ; Wed, 30 Jan 2002 00:19:33 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0U5Fkb28602; Wed, 30 Jan 2002 00:15:47 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 23:15:46 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE65@VA02> From: "Peterson, Jon" To: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] ambiguities with S/MIME Date: Tue, 29 Jan 2002 23:15:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Our decision to include more substantial text for S/MIME usage in bis06 was motivated by the absence of the PGP mechanism that appeared in RFC 2543, and by a set of known threats connected to the inspection or modification of bodies by intermediaries. Let's face it - not too many protocols grant as many opportunities as SIP for men-in-the-proverbial-middle to muck with messages. There was a general feeling that securing things end-to-end should happen at the level of MIME bodies, and S/MIME is sort of the natural (read: only) choice. We feared that without any mechanism for body security (or some mere lip-service along the lines of the bis05 text) it could be argued that the SIP standard doesn't provide a reasonable overall security story. On these grounds, despite the fact that the text undoubtedly has some blemishes, I think we should try to go forward with it. I think we can address the specific ambiguities you raise below without terrific effort (some notes below). I think our best bet is to get this text into as good a shape as we can and to go forward with it. We'd definitely appreciate any further comments along these lines. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rohan Mahy [mailto:rmahy@cisco.com] > Sent: Tuesday, January 29, 2002 6:01 PM > To: sip@ietf.org > Subject: [Sip] ambiguities with S/MIME > > [snip] > example ambiguities: > > it might be useful (especially with forking) to send the same > message/sip > signed with various certs that all correspond to me. how a UA would > handle multiple message/sip bodies is unclear. This has been raised a couple of times in connection with the S/MIME mechanism. Probably the simplest way of resolving this concern is to recommend that each S/MIME body be signed with only one cert, and to leave any behavior for handling multiple certs undefined (or at best suggesting that the outermost signature be treated as the single cert for this body). Same for multiple 'message/sip' bodies. > > if I can replace the "outer" To and From headers, which tags > do I use in a > Replaces header? If I receive an authenticated reINVITE in the clear > which operates on the "inside" To/From/Callid/tags, is this valid? > This is good - I certainly wouldn't want someone to get the impression that tunneling a message means that we're trying to set up some sort of second session based on the encapsulated signaling, or something. We should probably add a notice that the headers of an encapsulated 'message/sip' body are there for informational purposes and have no session semantics - they don't have dialog IDs or literally constitute some sort of tunneled session or what have you. Any session operations, including using things like Replaces, target the 'outer' headers. The value of using a transport protocol (in this instance SIP) to tunnel a SIP dialog between two fixed endpoints has been discussed in the past (notably in SIMPLE recently), and not really found very useful - two fixed endpoints don't really need the sorts of services that SIP provides; they might as well just trade MIME bodies. > obviously some headers shouldn't get replaced: > Via, Route, Record-Route are there any more? There is some text in 21.4.1 that speaks to the fact that some headers can be modified in transit without this constituting a breach in integrity. Realistically, this text should be popped up the stack to 21.4, since it applies to both types of tunneling. All of these headers are mentioned there. > > thoughts? > > 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 daemon@ns.ietf.org Wed Jan 30 00:50:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02556 for ; Wed, 30 Jan 2002 00:50:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA23644 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 00:50:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA22229; Wed, 30 Jan 2002 00:07:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA22200 for ; Wed, 30 Jan 2002 00:07:34 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01749 for ; Wed, 30 Jan 2002 00:07:33 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0U57d6Y007197; Wed, 30 Jan 2002 00:07:40 -0500 (EST) Message-ID: <3C577F72.A4AA1E58@dynamicsoft.com> Date: Wed, 30 Jan 2002 00:06:58 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: "SIP (E-mail)" Subject: Re: [Sip] new Register DoS attack References: <45730E094814E44488F789C1CDED27AEC55286@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit James Undery wrote: > > Hi, > > The recent (non normative) change to Registrar behaviour introduces a > new DoS attack against the registering UAC. There are a number of > variations of this attack, the attacker must be able to observe the UAC > REGISTER and send a re-REGISTER with an incremented CSeq. Next time the > UAC sends a REGISTER it will fail to update the bindings. The obvious > and lazy extension to this attack is to increment the CSeq by a larger > value (just within whatever a registrar will tolerate, bearing in mind > Proxy-Authentication may increase the CSeq legitimately in steps larger > than 1). Obviously the front-line defense here is request authentication with replay prevention, using something like nonce-count. I think this would solve the problem for a passive attacker. Thus, to launch this attack, you'd need to be a MITM, and that is a much harder attack to launch. Assuming you are a MITM, you could simply discard all registrations you receive, which has the same effect. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 30 01:56:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03076 for ; Wed, 30 Jan 2002 01:56:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA05233 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 01:56:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA03677; Wed, 30 Jan 2002 01:24:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA03644 for ; Wed, 30 Jan 2002 01:24:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02819 for ; Wed, 30 Jan 2002 01:24:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0U6Oj6Y007233; Wed, 30 Jan 2002 01:24:45 -0500 (EST) Message-ID: <3C579182.1EB1B3E1@dynamicsoft.com> Date: Wed, 30 Jan 2002 01:24:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mpierce1@aol.com CC: sip@ietf.org Subject: Re: [Sip] bis-06 now available! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I'm not sure if this is an insult or a complement. I read it as an insult (i.e, sip is getting bloated and we have the biggest spec ever produced by ietf). -Jonathan R. Mpierce1@aol.com wrote: > > In a message dated 1/28/02 6:32:35 AM Eastern Standard Time, > jdrosen@dynamicsoft.com writes: > > > Folks, > > > > I have just submitted an update to bis. Until it appears in the > > archives, you can pick it up at: > > > > > > > Comments, questions, and criticisms (and I'm sure people will have > them) > > are welcome. > > > > Thanks, > > Jonathan R. > > > Amazing work Jonathan and all. > > History of document size: > RFC2543 331k bytes > -02 381k bytes > -04 449k bytes > -05 510 k bytes > -06 667k bytes > > (Largest RFC published to date - 585k bytes) > > Will we reach 1meg before the next SIP RFC is published? > > 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 -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 30 02:10:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11474 for ; Wed, 30 Jan 2002 02:10:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA06144 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 02:10:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04865; Wed, 30 Jan 2002 01:42:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04762 for ; Wed, 30 Jan 2002 01:42:26 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02980 for ; Wed, 30 Jan 2002 01:42:25 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0U6e2gZ014861 for ; Wed, 30 Jan 2002 01:40:02 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 01:41:56 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338EA09@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Wed, 30 Jan 2002 01:41:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] The right solution to sip routing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks - In the process of studying the potential problem points with loose-routing as we've defined it so far, we've discovered that a slight change in the way we look at the problem has a high yeild. Basically, we want the Route mechanism to be right. We know we've long had an issue with the strict-routing mechanism in that it conflates the description of the next hop and the intended target - this is the source of all the pain with defining restrictions on loose routing such that reasonable things happen when strict-routers are part of the system. It is also the source of the convoluted proxy record-route/route processing we've had to date, including rewriting the RR URI so that it identifies the intended target in both directions and the odd RR/Contact munging that existed from bis-01 to -03. If we separate identifying the target from specifying the next hop, all those things go away. The change of approach is to look at what the sip routing mechanism would be if we had a clean slate. Find what the real "right thing" to do is, and then work in as much backwards compatibility with existing strict routing systems as is reasonable. So what is that right thing? What we want is for the Request-URI to represent the target of the request and the Route header field to indicate resources to visit on the path to that target. Instead of moving values from the route header field into the Request-URI, proxies would use the topmost route header field value to figure out where to send the request (using the normal address/port/transport selection mechanisms applied to that URI). Once the resource that is indicated by that topmost route header value is reached, then (and only then) that value is removed. More precisely, a proxy would execute the following steps in order: 1) Inspect the Request-URI, if it indicates a resource owned by this proxy, run a location service and rewrite the R-URI with the results. Otherwise, leave the R-URI alone. 2) Inspect the topmost Route header field value - if it indicates this element, that route node as been reached and it is removed. 3) Send the request to the resource in the topmost Route header field value using the normal address/port/transport resolution applied to that value (or using the Request-URI if the Route header field has been exhausted). Variations on those steps that meet the requirements in the looseroute proposal are valid, but its safe to say that the above represents the typical scenario. If every element behaves this way, the Request-URI is never overwritten with a Route header value, and Route header values are removed when the element is reached. This last point is pretty important. Only the node that the URI in that value indicates can truly know that the node has been reached. That URI can carry information critical to the processing at that node. Proxy record-routing becomes much simpler. The reason it's complex today is that the URI needs to both identify the proxy AND the ultimate recipient. With the right approach, it should just identify a service at that proxy. If there was only one service, the proxy could record-route with just its own address, which could be as simple as sip:1.2.3.4. In most cases, there would be no need to rewrite this in the response. Also, working with a clean slate, we would have UAs behave differently than they currently do when they have a route set. UAs should always place the target of the request in the Request-URI. So, given a preloaded route, the RURI of the initial request would indicate the resource the UA was trying to reach, and the Route header field would contain elements to be visited on the way. When a route set is established by receiving a response with a Record-Route header field, the UA puts the Contact from that response into the RURI of future request, NOT into Route header field as the last element. This way, the RURI indicates the real target of the request, and the Route header field represents elements that need to be visited to get there. So - if we could snap our fingers and have every deployed element do the above "right thing", we'ld be in great shape - unfortunately we have some deployed elements that will take time to change. What is their impact and what can we reasonably do to work with them? Encountering a strict-router while processing a request with preloaded routes will destroy the target information carried in the RURI. This is a hard and fast property of the way strict-routing is defined, and we cannot work around it without defining a new place to carry the "real" Request-URI. (Call it a Request-URI: header field for the sake of argument.) This is a terrible thing to do to the semantics of the protocol just to preserve backwards compatibility with elements doing something we find broken. The better approach is to bite the bullet, define the "right thing" as above, and live with the fact that encountering legacy strict-routers in the particular case of processing an initial request with a preloaded route will produce unpredictable results. However, we can assure that the most common usage of route headers, mid-dialog routing based on URIs learned in record-route/contact, will remain interoperable. Fortunately, we don't have real systems deployed that provide preloaded routes. Anybody building such a thing needs to know not to put strict-routing systems in it. People connecting such systems need to know not to put strict-routers between them. The case above is non-existant in deployed systems and with care, we can keep its probability of ever occuring near zero. We can make the story better for backwards compatibility with existing endpoints. If we add the following restriction to loose-routing proxy behavior, requests created by current endpoints building Route headers fields based on Record-Route header fields and Contacts will do the right thing: New Restriction 1: * If a proxy receives a request with an RURI equal to a value it placed in a Record-Route header, it MUST replace that RURI with the first value in the Route header field. This will cause the flow of these subsequent requests to effectively degenerate into the currently defined strict-routing behavior if a "new" proxy is in a routed path where upstream elements are "old" proxies or UAs. Now, we can make this even better by allowing elements that do the "right thing" advertise that fact to other elements that know what the right thing is. When such an element adds a value to a Record-Route header field, have it include a ;lr parameter in the value. When services create route sets to be used for preloaded routes, have them include the ;lr parameter on each value in that route set. With this knowledge, when an element (especially a "right thing" aware endpoint) is preparing to send a request to the topmost element in the Route set, it can notice that it is about to run into a chain of one or more strict-routing elements and can format the request so that any information it is carrying in the RURI is preserved. The mechanics of this are simple. If the request to send would otherwise have contained: METHOD targetURI Route ,,, (For instance, this might have been formed by a UA that got the targetURI from the Contact of a 200 to an INVITE, and built the Route header field by flipping the values it recieved in a Record-Route header field). the element can rebuild it to contain METHOD Route ,,,, Or, in text form, the element puts the target URI into the routeset after the first node indicating that it does the "right thing", and follows it with another copy of that nodes Route header value so that when that node gets the request, it can use its normal processing (we'll see that in action below). If there is no element in the Routee header field indicating that it will do the right thing, the element adds the target URI in as the last Route header field value. This gives the strict router the RequestURI it is expecting (and is going to ignore) as well as the proper topmost Route header field value to cause the request to move along the right path. When the request gets to the element indicated by right1;lr, it will look like METHOD rightthing1;lr Route ,, According to New Restriction 1 above, the element at right1 would replace the RURI with the topmost Route header field, rendering METHOD targetURI Route which the element at right1 can then apply its normal processing to. Note that this degenerates to existing UA behaviors when all elements are strict. When all elements understand this right thing, it results in the ideal behavior above, where Contact is in the URI, and the record-route headers are in the route headers. When there is a mix of proxies and UAs, the R-URI will have meaning for each element understanding how to do the right thing. I think this gives us the best story we're going to get. Here's a summary of what would change in bis: * Add the New Restriction 1 above * Define the ;lr parameter and when to include it * Add the above description of what we expect most proxy processing to be, emphasising the importance of having the element indicated by the topmost route header field value remove that value. * Simplify the proxy record-routing procedures * Add the above behavior for new UAs constructing requests from Route-sets (putting the Contact element from the routeset into the Request-URI instead of the last Route header field value. * Require all elements that know how to do this right thing to perform the manipulation above to get around a string of strict routing elements when they are encountered. The intent will be to gradually deprecate existing strict-routing. In the same vein, the uses of maddr that have evolved to try to get around some of the strict routing problems will be deprecated. Proxies implementing this new approach have no need to (MUST NOT) use maddr in any values they supply in Record-Route header fields. Here's an example flow that Jonathan worked out while we were discussing this: The scenario is the sip trapezoid, U1 -> P1 -> P2 -> U2, with both proxies record-routing. Here is the flow. U1 sends: INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com to P1. P1 is an outbound proxy. Following above rules, it isn't domain.com, and there are no Route headers, so it looks it up in DNS and sends there. It also record-routes: INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: P2 gets this. It owns domain.com. It runs a location service and rewrites the URI. There are no route headers, so it sends to the result of the location lookup. It also record-routes with its addres: INVITE sip:caleee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: Record-Route: The callee at u2 gets this. It responds with a 200 OK. That 200 OK looks like: SIP/2.0 200 OK Contact: sip:callee@u2.domain.com Record-Route: Record-Route: This is forwarded by P2 to P1 to U1 as normal. Now, U1 will construct the target, which is sip:callee@u2.domain.com, and a route set, which is sip:p1.example.com;lr, sip:p2.example.com;lr. Since all route hops are new, it constructs the following for the BYE: BYE sip:callee@u2.domain.com SIP/2.0 Route: Route: As any other element (including proxies) would do, it sends this request by looking up the top route in DNS, and sending there. This goes to P1. P1 follows same processing as before. The domain in the R-URI is not its own. So, it doesn't run location service, leaves r-uri alone. There is a route, which is its own, so its popped. THe next route is there, and its looked up in dns and the resulting address is used to forward the request to P2: BYE sip:callee@u2.domain.com SIP/2.0 Route: Now, P2 looks at this. The R-URI is NOT ITS DOMAIN, since u2.domain.com is a specific host. So, it does not run location service. Like P1, it notices the top route is its own, so its popped. There is no further route, so the r-uri is looekd up in dns, and that is used to forward. The following is then sent to u2: BYE sip:callee@u2.domain.com SIP/2.0 Voila! Everything works very nicely. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 30 02:43:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11881 for ; Wed, 30 Jan 2002 02:43:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA07794 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 02:43:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06348; Wed, 30 Jan 2002 02:17:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06313 for ; Wed, 30 Jan 2002 02:17:43 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11558 for ; Wed, 30 Jan 2002 02:17:42 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0U7Hl6Y007257; Wed, 30 Jan 2002 02:17:48 -0500 (EST) Message-ID: <3C579DEE.F3EABA4E@dynamicsoft.com> Date: Wed, 30 Jan 2002 02:17:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Michael Thomas'" , Juha Heinanen , "Rosen, Brian" , "'Dean Willis'" , sip@ietf.org Subject: Re: [Sip] TLS section References: <70565611B164D511957A001083FCDD56CAAE5B@VA02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Let me put my 2 cents in here. I think this whole debate is silly. First off, I did not think we indicated that either tls or ipsec was mandatory for UA; I think both are going to be equally inpalatable or not useful; we will need to handle that hop other ways. I thought we were talking between proxies. I like IPSec; we use it in some places in our architectures where I don't care that the proxy knows about the identity of the other side, and I want somehting I can slide in without affecting the proxy application itself. I also like TLS; I need it in some cases where I need to know the identity of the peer (inter-provider business relationships, in particular). There are roles for both TLS and IPSec. SIP allows both IPSec and TLS. Debating their merits is futile. You use when when its benefits are more important than its costs for that particular problem. The issue at hand is which is MUST, and which is MAY, in terms of implementation. Arguably, given that there are cases where IPSec is right and where TLS is right, you should make both of them MUST to provide interoperability. However, I think I would be visciously beaten by many folks for proposing that. Instead, a reasonable criteria for deciding might be: given the set of situations in which a hBh mechanism is needed, under what conditions would you run into a cross-provider interop situation, and in that situation, which would be the more appropriate choice for a mechanism, so that that particular mechanism would be available on both sides. Within a single provider network, you can always select products that support whichever protocol you prefer, so I don't think there is a real issue there. The main issue will arise cross-domain. In those cases, I would probably select TLS over IPSec, primarily because I would expect the proxy application would need to know who it was talking with. I would also expect that mutual auth based on PKI would be feasible and desirable here. Whilst that doesn't rule out IPSec, TLS is arguably easier to do for those things. -Jonathan R. "Peterson, Jon" wrote: > > Or maybe Juha would like TLS, because you don't have to do any manually > keying. > > Note that e-commerce requires a global PKI, but only so servers can > authenticate themselves to clients (via TLS). When a client > authenticates > itself to a server in the web, it uses HTTP Auth (i.e. Digest) to > communicate a username and password to the server. This assymetry is > exactly > what we're proposing for SIP. Distributing keys to servers, and > passwords to > users, is not a fantasy - it is a hard reality, and we can re-use this > for > SIP. > > When you give up that global server-side PKI, you give up the ability > for > SIP to be used in arbitrary interdomain contexts, where clients speak > securely to servers they've never addressed before. I think this would > be a > great loss for SIP, and I think we need it regardless of whether we > choose > TLS or IPSec. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, January 29, 2002 10:21 AM > > To: Juha Heinanen > > Cc: Michael Thomas; Rosen, Brian; 'Dean Willis'; Peterson, Jon; > > sip@ietf.org > > Subject: RE: [Sip] TLS section > > > > > > Juha Heinanen writes: > > > Michael Thomas writes: > > > > > > > > I know this argument well; it's the "any security > > takes too much > > > > > cpu/memory". I don't buy it. > > > > > > i don't care of cpu/memory, but i get mad if security makes > > > configuration of the ua more difficult than what it is w/o > > security or > > > if sip phones can't be used without a global pki. so > > whatever security > > > technology is chosen, it MUST be based on self generated > > keys so that > > > username/password is the only thing that needs to be > > configured in the > > > ua for security. > > > > Then you should like my proposal. In fact, you could > > use the exact same key that you use for digest, as well > > as share the code for MD5. > > > > 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 -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 30 02:50:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11940 for ; Wed, 30 Jan 2002 02:50:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA08072 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 02:50:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06598; Wed, 30 Jan 2002 02:24:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06567 for ; Wed, 30 Jan 2002 02:23:59 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11660 for ; Wed, 30 Jan 2002 02:23:58 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0U7O36Y007264; Wed, 30 Jan 2002 02:24:05 -0500 (EST) Message-ID: <3C579F66.AAFD2B48@dynamicsoft.com> Date: Wed, 30 Jan 2002 02:23:18 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Gonzalo Camarillo , Juha Heinanen , Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP References: <3C56F883.1E46E0BE@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > I do understand the reasons for using TCP, but why does it have to be a > "MUST"? My node may never send messages so big, and it may be used in a > network where it will never receive messages such big. > > Also, there may be nodes which will always communicate with a specific > outbound proxy, so they may use a "static" SCTP association for that. > > So, saying that nodes handling big messages shall use TCP (or similar) > is ok, but making TCP mandatory for EVERY node is another issue... The problem is this. You can control what you can send, but not what you will receive. If I send you a 2000 byte sip message, the spec says that your proxy has to use TCP to send it to you. If you don't support TCP, you won't get it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 30 02:51:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11980 for ; Wed, 30 Jan 2002 02:51:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA08192 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 02:51:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06658; Wed, 30 Jan 2002 02:24:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA06627 for ; Wed, 30 Jan 2002 02:24:51 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11669 for ; Wed, 30 Jan 2002 02:24:50 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0U7Opb29698 for ; Wed, 30 Jan 2002 02:24:51 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 01:24:51 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE68@VA02> From: "Peterson, Jon" To: sip@ietf.org Date: Wed, 30 Jan 2002 01:24:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] TLS, IPSec and consensus (bug #232) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I would like to suggest, based on the list discussion that has transpired to date, that the chairs consider whether or not we have rough consensus in favor of the current normative text on TLS and IPSec in bis06 22.3.1. The summary I sent out earlier today (along with Brian and Mike's summaries) provides an account of the current state of the discussion. I believe that the bis authors have been able to present a reasonable response to Mike's strenuous objections. In any event, the issues are on the table, and those who have debated these issues for months have essentially said their peace. If there are any further arguments, or reflections on TLS vs. IPSec transport vs. IPSec tunnel, from other members of the SIP community, let's hear them now, by all means. Most respondents have indicated that they can live with the text in bis06 today. I would also note that to date the reception of the proposed minimal IPSec profile (ESP transport mode HMAC-MD5-NULL) has been lukewarm, I think. Some respondents have expressed a preference for tunnel mode IPSec. The IESG also seems to feel that some encryption algorithm, as well as a story about keying, should be a part of an IPSec profile for SIP. While some encryption algorithms has been mentioned on the list (like DES, as required by RFC 2406), I haven't heard one that people sound entirely comfortable with. Ultimately, we all agree that we need to arrive at an IPSec profile for SIP - I just don't believe that we need to solve this problem in bis. Jon Peterson NeuStar, Inc. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 30 02:57:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12051 for ; Wed, 30 Jan 2002 02:57:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA08389 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 02:57:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07295; Wed, 30 Jan 2002 02:31:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07266 for ; Wed, 30 Jan 2002 02:31:23 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11738 for ; Wed, 30 Jan 2002 02:31:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0U7VY6Y007270; Wed, 30 Jan 2002 02:31:34 -0500 (EST) Message-ID: <3C57A129.377E6391@dynamicsoft.com> Date: Wed, 30 Jan 2002 02:30:49 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP References: <15445.60276.858845.659265@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Peterson, Jon writes: > > Today, SIP clients can use UDP without using IPSec, and that won't > change if > > we make IPSec mandatory to implement. Now that UDP and TCP are both > > mandatory in UAs, clients have a choice - either use UDP, which has > no > > recommended lower-layer security mechanism in the specification, or > use TCP, > > which you can secure with TLS. I don't see how this is 'incomplete' > just > > because a UA can choose to communicate in an insecure fashion. If all > proxy > > servers support TCP and TLS, then it sounds to me like a client that > > supports TLS can always make a secure connection. > > It's incomplete because a perfectly valid transport > mode -- UDP -- doesn't have a perfectly valid MUST > IMPLEMENT security scheme. What you're saying is > "if you want security, use TLS". That is not > helpful for when you use UDP. Agreed, it is not. IMHO, we need a non-transport oriented solution as the baseline for UA to proxy security functions. I believe that baseline is digest. While it certainly has many weaknesses that are well known, it is better than nothing, and has the benefit of being implementable and solving a reasonable class of attacks. TLS is better for smaller deployments, where the scale issues are not so bad that you can pay for the persistent connections. IPSec is not likely to be any better in terms of scale, since both have the same state issues. Once you move away from persistent connections, TLS suffers heavily from expensive setups that you will effectively repeat for each call, increasing latency and overhead. IPSec is similar; I dislike its keying mechanisms as well, but let us not dive into that, since its not really important for this point. So, since both TLS and IPSec have fatal flaws for large deployments, digest is preferred as the only broadly workable solution there. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 30 03:06:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12231 for ; Wed, 30 Jan 2002 03:06:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA09256 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 03:06:25 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08061; Wed, 30 Jan 2002 02:49:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08023 for ; Wed, 30 Jan 2002 02:49:56 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11921 for ; Wed, 30 Jan 2002 02:49:54 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0U7npX4005432; Wed, 30 Jan 2002 08:49:51 +0100 (MET) Received: from lmf.ericsson.se (lmf04630pc.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0U7nor6017041; Wed, 30 Jan 2002 09:49:50 +0200 (EET) Message-ID: <3C57A59C.F8211C80@lmf.ericsson.se> Date: Wed, 30 Jan 2002 09:49:48 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Gonzalo Camarillo , Juha Heinanen , Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP References: <3C56F883.1E46E0BE@lmf.ericsson.se> <3C579F66.AAFD2B48@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >>I do understand the reasons for using TCP, but why does it have to be a >>"MUST"? My node may never send messages so big, and it may be used in a >>network where it will never receive messages such big. >> >>Also, there may be nodes which will always communicate with a specific >>outbound proxy, so they may use a "static" SCTP association for that. >> >>So, saying that nodes handling big messages shall use TCP (or similar) >>is ok, but making TCP mandatory for EVERY node is another issue... > >The problem is this. You can control what you can send, but not what you >will receive. If I send you a 2000 byte sip message, the spec says that >your proxy has to use TCP to send it to you. If you don't support TCP, >you won't get it. The question is: when will you send me a 2000 byte sip message? When you use some specific SIP feature (eg instant messaging), or for a "basic" session setup? IF the argument is that the messages will be too big in "basic" situations, ie in situations where ANY (or, at least ALMOST ANY) UA node could be involved, I guess TCP must be supported. But, my argument (I don't have any numbers to prove this, and there are probably others who know about this more than I do) is that 2000 bytes will be enough for normal/basic situations. Using TCP for interproxy communication is ok, but if the UAS doesn't support TCP the last proxy before the UAS will have to try to find another server, or return an error response. Another question is: since the INVITE may be the only big message during the session, can I then switch from TCP to UDP in the middle of the session? What if there is an open TCP connection, but I still want to use UDP? Last, I don't have anything against TCP as such, but I just wonder if making a bunch of transport protocols mandatory for SIP is the right way to go - both from a protocol architecture point of view, but also from a pure technical point of view (you have to fit yet one more protocol in the small PDA...). Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Wed Jan 30 03:14:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12351 for ; Wed, 30 Jan 2002 03:14:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA09652 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 03:14:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08294; Wed, 30 Jan 2002 02:54:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08262 for ; Wed, 30 Jan 2002 02:54:51 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12028 for ; Wed, 30 Jan 2002 02:54:50 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0U7t16Y007278; Wed, 30 Jan 2002 02:55:01 -0500 (EST) Message-ID: <3C57A6A5.D501699F@dynamicsoft.com> Date: Wed, 30 Jan 2002 02:54:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Juha Heinanen , "Peterson, Jon" , "'Cullen Jennings'" , sip@ietf.org Subject: Re: [Sip] Summary of TLS discussion References: <15446.65533.591315.693326@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Juha Heinanen writes: > > Peterson, Jon writes: > > > > > - TLS has a good NAT traversal story. On several fronts > (enumerated in a > > > draft by Bernand Aboba), IPSec does not. > > > > i forgot this one. since nats are nowadays everywhere, the security > > solution MUST have a good nat story. otherwise sip will be dead on > > arrival. > > IPsec working group is working on a standards track > way of doing this. Basically, ESP over UDP. How does that help? UDP can still fragment, of course, and all fragmentation is bad as far as a NAT is concerned. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 03:27:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12460 for ; Wed, 30 Jan 2002 03:27:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA09945 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 03:27:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09413; Wed, 30 Jan 2002 03:08:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09382 for ; Wed, 30 Jan 2002 03:08:39 -0500 (EST) Received: from fra-tgn-oyy-vty21.as.wcom.net (root@fra-tgn-oyy-vty21.as.wcom.net [195.232.57.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12297 for ; Wed, 30 Jan 2002 03:08:36 -0500 (EST) Received: from rautu.eng.telia.fi (jh@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id g0U88LsG000695; Wed, 30 Jan 2002 10:08:21 +0200 Received: (from jh@localhost) by rautu.eng.telia.fi (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id g0U88IqA000691; Wed, 30 Jan 2002 10:08:18 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15447.43505.348316.789859@rautu.eng.song.fi> Date: Wed, 30 Jan 2002 10:08:17 +0200 To: Dean Willis Cc: Michael Thomas , Dean Willis , "Peterson, Jon" , "'Rosen, Brian'" , sip@ietf.org Subject: Re: [Sip] TLS section In-Reply-To: <200201292140.g0TLeLH02720@bdsl.66.12.12.130.gte.net> References: <70565611B164D511957A001083FCDD56CAAE49@VA02> <200201291850.g0TIo6H01594@bdsl.66.12.12.130.gte.net> <15447.2362.202362.391339@thomasm-u1.cisco.com> <200201292140.g0TLeLH02720@bdsl.66.12.12.130.gte.net> X-Mailer: VM 7.00 under Emacs 21.1.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dean Willis writes: > UA3 deduces the vitals of the UA1-UA2 session (To, From, CallID) and > spoofs a BYE. i don't get this. how can ua3 spoof the bye, because the proxy digest authenticates it? -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 04:00:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12758 for ; Wed, 30 Jan 2002 04:00:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11853 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 04:00:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10785; Wed, 30 Jan 2002 03:37:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10748 for ; Wed, 30 Jan 2002 03:37:53 -0500 (EST) Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12559 for ; Wed, 30 Jan 2002 03:37:50 -0500 (EST) Received: from lohi.eng.song.fi (localhost [127.0.0.1]) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) with ESMTP id g0U8bkio005934; Wed, 30 Jan 2002 10:37:46 +0200 Received: (from jh@localhost) by lohi.eng.song.fi (8.12.1/8.12.1/Debian -5) id g0U8bk01005930; Wed, 30 Jan 2002 10:37:46 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15447.45274.200235.964528@lohi.eng.song.fi> Date: Wed, 30 Jan 2002 10:37:46 +0200 To: Christer Holmberg Cc: Jonathan Rosenberg , Gonzalo Camarillo , Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP In-Reply-To: <3C57A59C.F8211C80@lmf.ericsson.se> References: <3C56F883.1E46E0BE@lmf.ericsson.se> <3C579F66.AAFD2B48@dynamicsoft.com> <3C57A59C.F8211C80@lmf.ericsson.se> X-Mailer: VM 6.97 under Emacs 20.7.2 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg writes: > The question is: when will you send me a 2000 byte sip message? When you > use some specific SIP feature (eg instant messaging), or for a "basic" > session setup? try to send a regular invite that includes digest authenticatin header and goes through three proxies each adding its record route, and viola, your invites is bigger than 1500 bytes when it hits the destination ua. for this reason ANY ua that plans to participate openly in sip telephony, for example, is liekly to get (uncompressed) messages that are larger than 1500 bytes. therefore, if the ua doesn't either support ip fragmentation (not recommened) or tcp, it will be out of luck. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 04:23:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13055 for ; Wed, 30 Jan 2002 04:23:04 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA12642 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 04:23:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12059; Wed, 30 Jan 2002 04:02:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12032 for ; Wed, 30 Jan 2002 04:02:15 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12821 for ; Wed, 30 Jan 2002 04:02:12 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g0U91sC03860; Wed, 30 Jan 2002 10:01:54 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0U91pr6022590; Wed, 30 Jan 2002 11:01:52 +0200 (EET) Message-ID: <3C57B67E.5634348C@lmf.ericsson.se> Date: Wed, 30 Jan 2002 11:01:50 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: Jonathan Rosenberg , Gonzalo Camarillo , Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP References: <3C56F883.1E46E0BE@lmf.ericsson.se> <3C579F66.AAFD2B48@dynamicsoft.com> <3C57A59C.F8211C80@lmf.ericsson.se> <15447.45274.200235.964528@lohi.eng.song.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, >try to send a regular invite that includes digest authenticatin header >and goes through three proxies each adding its record route, and viola, >your invites is bigger than 1500 bytes when it hits the destination ua. Well, I guess you have a point there. However, this also depends on the security mechanism used, and if the security mechanism itself authenticates the user. It also depends on when compression will be used, and how much it will help. The question is also who the caller on the SIP level authenticates himself with, ie if the authenticatin data has to be sent all the way to the UAS in the first place. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 04:37:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13252 for ; Wed, 30 Jan 2002 04:37:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA13659 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 04:37:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12534; Wed, 30 Jan 2002 04:18:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA12506 for ; Wed, 30 Jan 2002 04:18:42 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13020 for ; Wed, 30 Jan 2002 04:18:39 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 30 Jan 2002 09:19:05 UT content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] new Register DoS attack Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 30 Jan 2002 09:19:46 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE012F8202@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] new Register DoS attack Thread-Index: AcGpTBwDtlPLdJEIT0C0eu+IOb+7oAAIqUAg From: "James Undery" To: "Jonathan Rosenberg" Cc: "SIP (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA12507 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > James Undery wrote: > > > > Hi, > > > > The recent (non normative) change to Registrar behaviour > introduces a > > new DoS attack against the registering UAC. There are a number of > > variations of this attack, the attacker must be able to > observe the UAC > > REGISTER and send a re-REGISTER with an incremented CSeq. > Next time the > > UAC sends a REGISTER it will fail to update the bindings. > The obvious > > and lazy extension to this attack is to increment the CSeq > by a larger > > value (just within whatever a registrar will tolerate, > bearing in mind > > Proxy-Authentication may increase the CSeq legitimately in > steps larger > > than 1). > > Obviously the front-line defense here is request authentication with > replay prevention, using something like nonce-count. I think > this would > solve the problem for a passive attacker. Thus, to launch this attack, > you'd need to be a MITM, and that is a much harder attack to launch. > Assuming you are a MITM, you could simply discard all > registrations you > receive, which has the same effect. The problem is basically a non-issue but there are subtleties to this, i.e. to defeat this attack using a nonce-count requires the registrar to store state allowing state loading DoS attacks. 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 daemon@optimus.ietf.org Wed Jan 30 05:37:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14220 for ; Wed, 30 Jan 2002 05:37:12 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA15957 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 05:37:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15142; Wed, 30 Jan 2002 05:17:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15110 for ; Wed, 30 Jan 2002 05:17:09 -0500 (EST) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13915 for ; Wed, 30 Jan 2002 05:17:06 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 30 Jan 2002 10:17:32 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] The right solution to sip routing X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Date: Wed, 30 Jan 2002 10:18:15 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0112286F@GBNEWP0758M.eu.ubiquity.net> Thread-Topic: [Sip] The right solution to sip routing Thread-Index: AcGpWacSRZiBuhrOTQWrmPH8hcRNqgAHXgkw From: "Jo Hornsby" To: "Robert Sparks" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA15111 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Folks - [...] > Voila! Everything works very nicely. Wow. Very good. I'm 'pressed that you managed to weave such magic given the long legacy of specifications/implementations/ recommendations in a backwardly-compatible way, and still get near as damnit ideal behaviour. Certainly gets my vote. - Jo. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 08:54:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18536 for ; Wed, 30 Jan 2002 08:54:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA26609 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 08:55:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25032; Wed, 30 Jan 2002 08:31:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25004 for ; Wed, 30 Jan 2002 08:31:02 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17728 for ; Wed, 30 Jan 2002 08:31:00 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA16162; Wed, 30 Jan 2002 08:30:30 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA09198; Wed, 30 Jan 2002 08:30:31 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Jan 2002 08:30:30 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57C86E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Peterson, Jon'" , sip@ietf.org Subject: RE: [Sip] TLS, IPSec and consensus (bug #232) Date: Wed, 30 Jan 2002 08:30:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I dunno, I think I conclude that TLS and IPSec are roughly equal good/bad depending on the scenario you are advocating. I'd like to see a real IPSec profile defined in bis, and I think the one Mike proposed is acceptable, although if there is no objection to DES for confidentiality that's okay with me. I'd like to see a paragraph or two summarizing when IPSec is more appropriate and when TLS is more appropriate along the lines of Jonathan's email. I'd like to see a distinction between what a UA should/must do and what a PS should/must do. I'd like the UA to not have to should/must either TLS or IPsec, but rather be content with Digest. I'd like to see some words that basically say that PS intended to work within a domain must implement IPSec, and PSs intended to work cross domain must implement TLS and both should implement both. Brian > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Wednesday, January 30, 2002 2:25 AM > To: sip@ietf.org > Subject: [Sip] TLS, IPSec and consensus (bug #232) > > > > I would like to suggest, based on the list discussion that > has transpired to > date, that the chairs consider whether or not we have rough > consensus in > favor of the current normative text on TLS and IPSec in bis06 22.3.1. > > The summary I sent out earlier today (along with Brian and > Mike's summaries) > provides an account of the current state of the discussion. I > believe that > the bis authors have been able to present a reasonable > response to Mike's > strenuous objections. In any event, the issues are on the > table, and those > who have debated these issues for months have essentially > said their peace. > If there are any further arguments, or reflections on TLS vs. IPSec > transport vs. IPSec tunnel, from other members of the SIP > community, let's > hear them now, by all means. Most respondents have indicated > that they can > live with the text in bis06 today. > > I would also note that to date the reception of the proposed > minimal IPSec > profile (ESP transport mode HMAC-MD5-NULL) has been lukewarm, > I think. Some > respondents have expressed a preference for tunnel mode > IPSec. The IESG also > seems to feel that some encryption algorithm, as well as a story about > keying, should be a part of an IPSec profile for SIP. While > some encryption > algorithms has been mentioned on the list (like DES, as > required by RFC > 2406), I haven't heard one that people sound entirely > comfortable with. > > Ultimately, we all agree that we need to arrive at an IPSec > profile for SIP > - I just don't believe that we need to solve this problem in bis. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachment, use the contents for any purposes, or disclose the contents to any other person: to do so could be a breach of confidence. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 08:55:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18552 for ; Wed, 30 Jan 2002 08:55:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA26624 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 08:55:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25465; Wed, 30 Jan 2002 08:38:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA25354 for ; Wed, 30 Jan 2002 08:38:29 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17926 for ; Wed, 30 Jan 2002 08:38:26 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0UDbu822601 for ; Wed, 30 Jan 2002 08:37:56 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0UDbsh28858 for ; Wed, 30 Jan 2002 08:37:54 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 08:37:57 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102AF4A@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Dean Willis'" , sip@ietf.org, wtm@research.att.com, Flemming Andreasen Subject: RE: [Sip] Discussion of draft-ietf-sip-privacy-03 issues. Date: Wed, 30 Jan 2002 08:37:56 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Your points all make sense to me. Obviously, some sort of integrity protection has to go along with this. I also wonder whether we have to allow each successive service provider on the signalling path to add its bit saying the previous certifying entity could be trusted, so a chain of trust is built up on the fly. -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, January 29, 2002 5:53 PM To: sip@ietf.org; wtm@research.att.com; Flemming Andreasen Subject: [Sip] Discussion of draft-ietf-sip-privacy-03 issues. draft-ietf-sip-privacy-03 does several notable things. 1) It defines a Remote-Party-ID header, which provides a way to state the identity of participants in a dialog, as well as describe some things about that identity, such directionality and its stutus as a device or human identity. 2) It provides the RPID-privacy header, which allows the end node to describe the privacy policy it wishes to have applied to any Remote-Party-ID headers added by intermediate nodes. 3) It provides an "Anonymity" header, which may requests some intermediate node to route the dialog via an "anonimyzer", essentially a trusted B2BUA that provides additional privacy protections for the requesting node. Let me start with #3, the "Anonymity" header. This appears to be the request for a specific routing service or feature which may or may not be available in a given network. I think some generalization of the expression is appropriate, and it may be worthwhile considering such alternatives as making this into a request parameter or as a specific service such as that targedted in RFC 2084. In general, I propose that the "Anonymity" header be extracted from this document and taken into a seperate body of work. #1 and #2, the Remote-Party-ID (RPID) header, and "RPID-Privacy" are deeply intertwingled. There is an implicit assumption in the draft that "the network" is a monolithic entity with a relatively homogenous trust fabric. This is consistent with the draft's stated goal of providing "NETWORK authenticated RPID", as opposed to RPIDs asserted by other parties, or by specific networks. There are a couple of things that the RPID syntax as drafted does not do that may be worthwhile to consider. 1) Informing us as to WHO has asserted the given RPID. The draft allows either the user, the terminal or "the network" to assert an RPID, but gives no indication as to which element has made the assertion. It might be useful to know which user, which network element, or even "which network" asserted the RPID. Such an identification may also be useful in selecting a decryption key, should the option of protecting the privacy by encrypting the asserted identity be exercised. 2) Informing us at to WHEN each assertion of RPID was made. This is a critical aspect for considering replay attacks, as a "stale" assertion seems more likley to be false. Of couse there are issues of absolute time and clock synchronization to consider, but there are discussions of using the RPID as a identity "ticket" for (ala Kerberos), and the value of time-awareness in ticket environments is well-understood. One might consider seprately the utility of indicating a duration for the assertion in relative-time terms. 3) Informing us as to the dialog-context in whch the assertion of identity is being made. Common SIP usage identifies the session-context as consisting of the tuple of To:, From:, and Call-ID: headers. Without this context, we have no way of knowing if the dialog has undergone a "retargeting" transformation since the identity was asserted. As drafted, we can assume that the assertion was made in the current dialog-context, but we have no way to verify that assumption and must relay on transitive trust back to the currently unidentfied asserting party. 4) Allowing us to verify, or authenticate, each assertion of RPID. It seems desirable to provide an authentication-token for each RPID which provides the ability to match the asserted RPID with the asserting identity, the time of the assertion, and the context of the assertion. One migh propose to achieve this by hashing the conetxt (To:, From, Call-ID) together with the asserting identity and the time of theassertion, using either a secret or public key associated with the asserting identity. It has been previously pointed out (MAT) that a verification token such as that proposed above (#4) is subject to replay. Specifically, it is possible for a party in possession of an RPID assertion to replay it for the same combination of context-determining parameters (To, From, Call-ID). It may be noted that time-bounding the assertion (as in #2 above) mitigates this problem to some extent, while adding the requirement for some general synchronization of clocks in order to provide this protection. On the other hand, it can be countered that the utility of such a mechanism, while imperfect, is significantly better than the warm but vacuous feeling one might get from implementing the orginal proposal. So, other than pretending I've been reading too much Dumas, I would like to poll the list for relevant suggestions. Should we adopt any or all of the four specific requirements given herein (asserting identity, time of assertion, context of assertion, and verification of assertion) into the RPID work? Should we also move the "Anonymity" header into a seperate draft as suggested? Thanks, -- Dean Willis _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 11:07:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23539 for ; Wed, 30 Jan 2002 11:07:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05512 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:07:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03553; Wed, 30 Jan 2002 10:36:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03523 for ; Wed, 30 Jan 2002 10:36:51 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22656 for ; Wed, 30 Jan 2002 10:36:49 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA25172; Wed, 30 Jan 2002 10:36:30 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0UFaSJ1018457; Wed, 30 Jan 2002 10:36:28 -0500 (EST) Message-ID: <3C5812FC.51CF80AE@cs.columbia.edu> Date: Wed, 30 Jan 2002 10:36:28 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] ambiguities with S/MIME References: <70565611B164D511957A001083FCDD56CAAE65@VA02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > bodies by intermediaries. Let's face it - not too many protocols grant as > many opportunities as SIP for men-in-the-proverbial-middle to muck with Well, minor protocols like HTTP or SMTP come to mind, but I guess they are not widely used :-) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 11:19:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23836 for ; Wed, 30 Jan 2002 11:19:31 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06083 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:19:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03685; Wed, 30 Jan 2002 10:39:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03656 for ; Wed, 30 Jan 2002 10:39:43 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22758 for ; Wed, 30 Jan 2002 10:39:41 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA25431; Wed, 30 Jan 2002 10:39:34 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0UFdXJ1018583; Wed, 30 Jan 2002 10:39:33 -0500 (EST) Message-ID: <3C5813B5.CBFE6E5D@cs.columbia.edu> Date: Wed, 30 Jan 2002 10:39:33 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Mpierce1@aol.com, sip@ietf.org Subject: Re: [Sip] bis-06 now available! References: <3C579182.1EB1B3E1@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I'm not sure if this is an insult or a complement. I read it as an > insult (i.e, sip is getting bloated and we have the biggest spec ever > produced by ietf). If we're lucky, we may just miss that distinction, due to the removal of all the changes sections (except for the "big picture" summary). However, I think the point made implicitly is a valid one - there has been a temptation to turn the RFC into a deployment manual and software specification. People proposing ever more elaborate philosophical text on the state of the world might want to keep the costs in mind. Specs become bloated one paragraph and one good intention at a time... -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 11:19:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23854 for ; Wed, 30 Jan 2002 11:19:34 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06098 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:19:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04505; Wed, 30 Jan 2002 10:51:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04466 for ; Wed, 30 Jan 2002 10:51:30 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23133 for ; Wed, 30 Jan 2002 10:51:25 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA27014; Wed, 30 Jan 2002 10:50:59 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0UFowJ1019191; Wed, 30 Jan 2002 10:50:58 -0500 (EST) Message-ID: <3C581662.770A91EA@cs.columbia.edu> Date: Wed, 30 Jan 2002 10:50:58 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Jonathan Rosenberg , Gonzalo Camarillo , Juha Heinanen , Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP References: <3C56F883.1E46E0BE@lmf.ericsson.se> <3C579F66.AAFD2B48@dynamicsoft.com> <3C57A59C.F8211C80@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Also, despite various political correctness issues, UDP will work unless you have a conflation of two things: - messages greater than (say) 1,500 bytes - a NAT between the last-hop proxy and the UA OR - a highly lossy link (> 5% loss, say) (With 10% loss, the probability that a two-fragment packet won't make it is about 19%, assuming independent losses.) Thus, I suspect that a robust implementation that will find a UDP-only (e.g., RFC 2543) implementation will attempt to send a larger UDP packet anyway. At least that way, there's a chance that it will succeed. In many cases of interest, the chance is actually close to 100%. (E.g., in our local network, with existing UDP-only SIP phones and no NATs and maybe a one-in-a-million packet loss ratio. For others, where the proxy is an ALG, this holds for NAT-challenged networks as well.) I'll go to UDP political correctness training now, thank you. Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 11:22:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23949 for ; Wed, 30 Jan 2002 11:22:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06202 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:22:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04417; Wed, 30 Jan 2002 10:50:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04385 for ; Wed, 30 Jan 2002 10:50:51 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23095 for ; Wed, 30 Jan 2002 10:50:49 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g0UFn3H09441; Wed, 30 Jan 2002 09:49:03 -0600 Message-Id: <200201301549.g0UFn3H09441@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-1" From: Dean Willis To: Juha Heinanen , Dean Willis Subject: Re: [Sip] TLS section Date: Wed, 30 Jan 2002 09:49:01 -0600 X-Mailer: KMail [version 1.3.2] Cc: Michael Thomas , Dean Willis , "Peterson, Jon" , "'Rosen, Brian'" , sip@ietf.org References: <70565611B164D511957A001083FCDD56CAAE49@VA02> <200201292140.g0TLeLH02720@bdsl.66.12.12.130.gte.net> <15447.43505.348316.789859@rautu.eng.song.fi> In-Reply-To: <15447.43505.348316.789859@rautu.eng.song.fi> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I have yet to see a system actually authenticate BYE. Otherwise, an external caller could never hang up . . . -- Dean On Wednesday 30 January 2002 02:08 am, Juha Heinanen wrote: > Dean Willis writes: > > UA3 deduces the vitals of the UA1-UA2 session (To, From, CallID) > > and spoofs a BYE. > > i don't get this. how can ua3 spoof the bye, because the proxy > digest authenticates it? > > -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 11:23:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23989 for ; Wed, 30 Jan 2002 11:23:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06238 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:23:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03856; Wed, 30 Jan 2002 10:41:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03825 for ; Wed, 30 Jan 2002 10:41:41 -0500 (EST) Received: from imo-m05.mx.aol.com (imo-m05.mx.aol.com [64.12.136.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22850 for ; Wed, 30 Jan 2002 10:41:40 -0500 (EST) From: Mpierce1@aol.com Received: from Mpierce1@aol.com by imo-m05.mx.aol.com (mail_out_v31_r1.26.) id d.c.2236ffd4 (4396); Wed, 30 Jan 2002 10:41:03 -0500 (EST) Message-ID: Date: Wed, 30 Jan 2002 10:41:02 EST Subject: Re: [Sip] calling number blocking at sip/isup gateway To: dean.willis@softarmor.com, sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In a message dated 1/29/02 11:57:47 AM Eastern Standard Time, dean.willis@softarmor.com writes: > On Tuesday 29 January 2002 07:27 am, Mpierce1@aol.com wrote: > > However, because of other security concerns, a real IP telephone > > service provider would require that it knows the identity of the > > calling party and the model for this service must be based on a > > presumption that the calling party can trust the service provider. > > Therefore, in this case, the From must contain a correct number, and > > the gateway may remove it (after verifying it). > > > > The case of the calling party leaving out the From can not be used in > > a "tariffed" (if I can use that term) telephone service. While the > > SIP protocol may allow it to be left out, the service provider may > > require it before allowing call setup. > > I run a real IP telephone service. Unknown parties may place calls over > the Internet to my subscribers. My subscribers's profiles may result in > forwarding those calls to a PSTN gateway. PSTN charges originating from > this operation are charged back to the subscriber (the called party), > not the calling party with whom I have no relationship outside the SIP > used to set up the call. > > It really doesn't matter what the calling party put in their From: > field, I still need to complete the call. Now, if they were kind enough > to put in a phone number, I can map that into the IAM. But if they > didn't, I just can't. Now, there's an interesting question on > "authenticating" the phone number that they might have included., but > that's a different problem. > > Even more interesting, I'm going to include any referenceable number > from the INVITE in the IAM, regardless of any privacy indicator > suggested by the SIP signaling, because that referencable number would > have been included in the SIP signal delivered to my subscriber anyhow > (The caller DID send it to him), and my job as a gateway oeprator is to > get as much of the SIP experience as possible into the call being > forwarded to the PSTN. > > So, here we have a real phone service which conflicts with the > behavioral requirements suggested by mpierce's post, as well as a > whole can of privacy and transitive trust worms. > > -- > Dean > I was speaking of the service provider who handles the call origination. They must know the identity of the caller. (Note the e-mail from Juha about Finland.) I believe you are talking about a service provider who handles the destination or someplace in the middle of the call routing. Just like in the PSTN today, it only needs to trust the service provider it got the call setup from, so it does not require the originating party's ID at the destination. (It's nice if it's there, but not required.) What bothers me is that we are modeling this on current stuff, and yesterday I got two copies of the new "Party" virus attached to e-mails from "UnknownSender". If we can't stop this in e-mail today, what is the future telephony network going to be like? 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 daemon@optimus.ietf.org Wed Jan 30 11:30:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24191 for ; Wed, 30 Jan 2002 11:30:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA06707 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:30:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04757; Wed, 30 Jan 2002 10:57:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04729 for ; Wed, 30 Jan 2002 10:57:21 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23325 for ; Wed, 30 Jan 2002 10:57:19 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA27554; Wed, 30 Jan 2002 10:57:13 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0UFvBJ1019360; Wed, 30 Jan 2002 10:57:12 -0500 (EST) Message-ID: <3C5817D7.DD353437@cs.columbia.edu> Date: Wed, 30 Jan 2002 10:57:11 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: James Undery CC: Jonathan Rosenberg , "SIP (E-mail)" Subject: Re: [Sip] new Register DoS attack References: <45730E094814E44488F789C1CDED27AE012F8202@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit James Undery wrote: > > The problem is basically a non-issue but there are subtleties to this, > i.e. to defeat this attack using a nonce-count requires the registrar to > store state allowing state loading DoS attacks. Also, the state here is bounded by the number of registrations. Thus, the effect is different than, say, in a general server system. If each registration takes N bytes of memory, the worst-case effect is N+C, where C is the nonce counter. Since C << N, this is not likely to be a major problem. (This is slightly simplified, due to having multiple UA for registration, but that tends to be a small scale factor.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 11:38:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24411 for ; Wed, 30 Jan 2002 11:38:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07243 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:38:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05701; Wed, 30 Jan 2002 11:10:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05669 for ; Wed, 30 Jan 2002 11:10:55 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23666 for ; Wed, 30 Jan 2002 11:10:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UGB46Y007560; Wed, 30 Jan 2002 11:11:05 -0500 (EST) Message-ID: <3C581AEF.1E2B4C84@dynamicsoft.com> Date: Wed, 30 Jan 2002 11:10:23 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby CC: Robert Sparks , sip@ietf.org Subject: Re: [Sip] The right solution to sip routing References: <45730E094814E44488F789C1CDED27AE0112286F@GBNEWP0758M.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Thanks for the support, Jo. I'd also like to say a few words on this. After years of changes and fixes and patches and modifications, I *finally* feel like we have it right. I am certain that the ideal behavior in the note Robert sent is the right one. The only ugliness around the mechanism surrounds the requirement for mucking with the route set in order to handle downstream strict routers; this actually will go away as proxies and UAs get upgraded to bis. It is my hope and expectation that this aspect of the specification would be removed when we rev to draft, and it was part of our goals to define a mechanism which would not "leave a mess forever", allowing the interim mechanisms to only get invoked when needed. An important benefit of the mechanism, which Robert mentions, is the ability to finally discard the maddr parameter in the URI. maddr is really the earliest legacy of our attempts at source routing. I think it is clear that it should be discarded when you think about things in terms of names, addresses, and routes. The URI is a name/address, but definitely NOT a route. However, maddr is clearly a parameter for routing, and thus does not belong in the URI. We needed it because initially, we needed a way for a proxy to create a URL that BOTH indicated the final destination AND the hop to get there. By formally separating these now, as it should be, the need for maddr disappears. This provides a nice resolution of the various problems we have found in the interpretation of transport and port in the URI when maddr was present, in addition to proxy processing logic in the presence of maddr in the r-uri. THis causes confusion since it effectively presents two independent routing guidelines - the URI, and the Route headers, and there are precedence issues which are hard to resolve. The proposal helps resolve them by making sure there is one mechanism for routing. The mechanism also makes the way much easier for a formal definition of the Path header. Now, it becomes just like record-route - it represents a hop. The difference is only one of scope. The UA uses it to learn of pre-loaded routes to a particular domain, and the registrar uses it to learn of pre-loaded routes to a client. A proxy inserts one when it wishes to be on a pre-loaded route to that domain, or in the path of calls from that domain back to the UA. The scope of it depends on the message its carried in; for REGISTER, its scoped to the lifetime of the registration. But, it seems like it would even be useful to allow Path in something like OPTIONS, which would allow a UA to learn of preloaded routes to a domain without having to register to that domain. 3gpp can elect not to use it, but it would allow for a more general "pre-loaded route discovery" tool which could be used without binding outgoing calls to a registration. I'll send a separate note with an example flow of how I think it should work based on this new mechanism. Much thanks to Robert for doing a tremendous amount of working in getting us from where we were to where we are now. Arguably the hardest and most important problem in SIP is now licked! -Jonathan R. Jo Hornsby wrote: > > > Folks - > [...] > > Voila! Everything works very nicely. > > Wow. > > Very good. > > I'm 'pressed that you managed to weave such magic given > the long legacy of specifications/implementations/ > recommendations in a backwardly-compatible way, and still > get near as damnit ideal behaviour. > > Certainly gets my vote. > > - Jo. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 11:38:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24432 for ; Wed, 30 Jan 2002 11:38:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07267 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:38:47 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05989; Wed, 30 Jan 2002 11:16:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05958 for ; Wed, 30 Jan 2002 11:16:18 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23766 for ; Wed, 30 Jan 2002 11:16:16 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UGFt6Y007563; Wed, 30 Jan 2002 11:15:55 -0500 (EST) Message-ID: <3C581C11.D0FDD579@dynamicsoft.com> Date: Wed, 30 Jan 2002 11:15:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Mpierce1@aol.com, sip@ietf.org Subject: Re: [Sip] bis-06 now available! References: <3C5813B5.CBFE6E5D@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Henning G. Schulzrinne" wrote: > > Jonathan Rosenberg wrote: > > > > I'm not sure if this is an insult or a complement. I read it as an > > insult (i.e, sip is getting bloated and we have the biggest spec ever > > produced by ietf). > > If we're lucky, we may just miss that distinction, due to the removal of > all the changes sections (except for the "big picture" summary). Right. Allison has asked for a single section summarizing the real normative changes since rfc2543. This new section will be present in bis-07 on Monday, I hope. > > However, I think the point made implicitly is a valid one - there has > been a temptation to turn the RFC into a deployment manual and software > specification. People proposing ever more elaborate philosophical text > on the state of the world might want to keep the costs in mind. Specs > become bloated one paragraph and one good intention at a time... Sure, but its a tradeoff just like everything we do at IETF. Too little "deployment manual" materials will be a recipe for interop failures; our lesson over the years was that more was needed beyond rfc2543, IMHO. Too much, and you dictate architectures and implementations, and thus loose the flexibility of SIP and make it hard to read at the same time. I think rfc2543 was too much towards the side of underspecified. I think that bis is closer to the mark, perhaps erring slightly on the side of hand-holding than under specification, but I think thats OK. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 11:48:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24778 for ; Wed, 30 Jan 2002 11:48:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07937 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:49:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06162; Wed, 30 Jan 2002 11:21:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06128 for ; Wed, 30 Jan 2002 11:21:23 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23920 for ; Wed, 30 Jan 2002 11:21:20 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0UGKHL08908; Wed, 30 Jan 2002 08:20:17 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAU00780; Wed, 30 Jan 2002 08:19:46 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA21957; Wed, 30 Jan 2002 08:20:16 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.7488.452360.37353@thomasm-u1.cisco.com> Date: Wed, 30 Jan 2002 08:20:16 -0800 (PST) To: "Henning G. Schulzrinne" Cc: Christer Holmberg , Jonathan Rosenberg , Gonzalo Camarillo , Juha Heinanen , Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP In-Reply-To: <3C581662.770A91EA@cs.columbia.edu> References: <3C56F883.1E46E0BE@lmf.ericsson.se> <3C579F66.AAFD2B48@dynamicsoft.com> <3C57A59C.F8211C80@lmf.ericsson.se> <3C581662.770A91EA@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Henning G. Schulzrinne writes: > I'll go to UDP political correctness training now, thank you. I guess we should go together because I'm having a hard time imagining how the situation with SIP could be even 1/10th as bad as the punishment that HTTP 1.0 caused the net. I think the net is more resilient than most people give it credit for. The simple solution of mandating TCP implemention but not forcing its use (even when you'd fragment) until there's some *real* empirical evidence that the amount of fragmentation caused by SIP causes global harm seems a lot more prudent than the compromise in bis right now. If we're eventually proven wrong (and properly reeducated), we simply get out the word that TCP is safer and more robust which would only require a small change on the UA's. BTW: I think that the MUST TCP is probably a good thing generally and not just because of message size considerations. 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 daemon@optimus.ietf.org Wed Jan 30 11:56:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25044 for ; Wed, 30 Jan 2002 11:56:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08368 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:56:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07055; Wed, 30 Jan 2002 11:32:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07028 for ; Wed, 30 Jan 2002 11:32:48 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24265 for ; Wed, 30 Jan 2002 11:32:46 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UGWS6Y007588; Wed, 30 Jan 2002 11:32:28 -0500 (EST) Message-ID: <3C581FF2.D127BC6A@dynamicsoft.com> Date: Wed, 30 Jan 2002 11:31:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: "Peterson, Jon" , "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] ambiguities with S/MIME References: <3C5812FC.51CF80AE@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Henning G. Schulzrinne" wrote: > > "Peterson, Jon" wrote: > > > > > bodies by intermediaries. Let's face it - not too many protocols grant > as > > many opportunities as SIP for men-in-the-proverbial-middle to muck > with > > Well, minor protocols like HTTP or SMTP come to mind, but I guess they > are not widely used :-) In Jon's defense, a user-to-user protocol like SIP has far more vulnerabilities than HTTP; after all, if it were as easy as HTTP, why would we need anything beyond TLS+digest? I think we all agree we do need more than that. I'll further add that SIP is also harder than SMTP because (1) of its reach all the way to the user, (2) its creation of session/dialog state which can be affected by subsequent messages. The second point being the real rub. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 11:56:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25063 for ; Wed, 30 Jan 2002 11:56:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08398 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 11:56:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07103; Wed, 30 Jan 2002 11:33:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07074 for ; Wed, 30 Jan 2002 11:33:08 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24274 for ; Wed, 30 Jan 2002 11:33:06 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0UGWUL21777; Wed, 30 Jan 2002 08:32:31 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAU00988; Wed, 30 Jan 2002 08:32:00 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA21961; Wed, 30 Jan 2002 08:32:30 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.8222.86872.841578@thomasm-u1.cisco.com> Date: Wed, 30 Jan 2002 08:32:30 -0800 (PST) To: Jonathan Rosenberg Cc: Christer Holmberg , Gonzalo Camarillo , Juha Heinanen , Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP In-Reply-To: <3C579F66.AAFD2B48@dynamicsoft.com> References: <3C56F883.1E46E0BE@lmf.ericsson.se> <3C579F66.AAFD2B48@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > > > Christer Holmberg wrote: > > > > Hi, > > > > I do understand the reasons for using TCP, but why does it have to be a > > "MUST"? My node may never send messages so big, and it may be used in a > > network where it will never receive messages such big. > > > > Also, there may be nodes which will always communicate with a specific > > outbound proxy, so they may use a "static" SCTP association for that. > > > > So, saying that nodes handling big messages shall use TCP (or similar) > > is ok, but making TCP mandatory for EVERY node is another issue... > > The problem is this. You can control what you can send, but not what you > will receive. If I send you a 2000 byte sip message, the spec says that > your proxy has to use TCP to send it to you. If you don't support TCP, > you won't get it. Jonathan, I'm having a real hard time understanding why it is beneficial to the net if the UAC accepts the TCP connection for a large response and then immediately shuts down the connection. That seems like an extra 6 messages to me. I'm assuming that the UAC probably prefers UDP for some reason -- like it or the proxy/UAS doesn't want to keep the TCB around long term, etc. Now, I have less disagreement if the UAC initiates a large message, but as with my previous mail to Henning, I'm worried that this might even be tempest in a teapot. 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 daemon@optimus.ietf.org Wed Jan 30 12:09:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25459 for ; Wed, 30 Jan 2002 12:09:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10156 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:10:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08015; Wed, 30 Jan 2002 11:49:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07893 for ; Wed, 30 Jan 2002 11:48:59 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24773 for ; Wed, 30 Jan 2002 11:48:56 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UGn86Y007607; Wed, 30 Jan 2002 11:49:09 -0500 (EST) Message-ID: <3C5823DC.ECFE2495@dynamicsoft.com> Date: Wed, 30 Jan 2002 11:48:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" CC: "'Peterson, Jon'" , sip@ietf.org Subject: Re: [Sip] TLS, IPSec and consensus (bug #232) References: <313680C9A886D511A06000204840E1CF57C86E@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree with Brian on all points; as for the IPSec profile, I'm for it if one can be defined in a reasonable time frame and make the various security folks happy. If its going to delay SIP one bit, we should not try to tackle it here. -Jonathan R. "Rosen, Brian" wrote: > > I dunno, I think I conclude that TLS and IPSec > are roughly equal good/bad depending on the > scenario you are advocating. I'd like to see > a real IPSec profile defined in bis, and I think the > one Mike proposed is acceptable, although if > there is no objection to DES for confidentiality > that's okay with me. > > I'd like to see a paragraph or two summarizing > when IPSec is more appropriate and when TLS is > more appropriate along the lines of Jonathan's > email. > > I'd like to see a distinction between what a UA > should/must do and what a PS should/must do. > I'd like the UA to not have to should/must > either TLS or IPsec, but rather be content > with Digest. I'd like to see some words that > basically say that PS intended to work > within a domain must implement IPSec, and > PSs intended to work cross domain must implement > TLS and both should implement both. > > Brian > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Wednesday, January 30, 2002 2:25 AM > > To: sip@ietf.org > > Subject: [Sip] TLS, IPSec and consensus (bug #232) > > > > > > > > I would like to suggest, based on the list discussion that > > has transpired to > > date, that the chairs consider whether or not we have rough > > consensus in > > favor of the current normative text on TLS and IPSec in bis06 22.3.1. > > > > The summary I sent out earlier today (along with Brian and > > Mike's summaries) > > provides an account of the current state of the discussion. I > > believe that > > the bis authors have been able to present a reasonable > > response to Mike's > > strenuous objections. In any event, the issues are on the > > table, and those > > who have debated these issues for months have essentially > > said their peace. > > If there are any further arguments, or reflections on TLS vs. IPSec > > transport vs. IPSec tunnel, from other members of the SIP > > community, let's > > hear them now, by all means. Most respondents have indicated > > that they can > > live with the text in bis06 today. > > > > I would also note that to date the reception of the proposed > > minimal IPSec > > profile (ESP transport mode HMAC-MD5-NULL) has been lukewarm, > > I think. Some > > respondents have expressed a preference for tunnel mode > > IPSec. The IESG also > > seems to feel that some encryption algorithm, as well as a story about > > keying, should be a part of an IPSec profile for SIP. While > > some encryption > > algorithms has been mentioned on the list (like DES, as > > required by RFC > > 2406), I haven't heard one that people sound entirely > > comfortable with. > > > > Ultimately, we all agree that we need to arrive at an IPSec > > profile for SIP > > - I just don't believe that we need to solve this problem in bis. > > > > Jon Peterson > > NeuStar, Inc. > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > This e-mail and any attachments are confidential. If you are not the > intended recipient, please notify us immediately by reply e-mail and > then > delete this message from your system. Do not copy this e-mail or any > attachment, use the contents for any purposes, or disclose the contents > to > any other person: to do so could be a breach of confidence. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 12:12:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25584 for ; Wed, 30 Jan 2002 12:12:13 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10268 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:12:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08184; Wed, 30 Jan 2002 11:52:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08151 for ; Wed, 30 Jan 2002 11:52:15 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24905 for ; Wed, 30 Jan 2002 11:52:13 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UGqQ6Y007616; Wed, 30 Jan 2002 11:52:26 -0500 (EST) Message-ID: <3C5824A1.1A6D9E4C@dynamicsoft.com> Date: Wed, 30 Jan 2002 11:51:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] ambiguities with S/MIME References: <70565611B164D511957A001083FCDD56CAAE65@VA02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > > it might be useful (especially with forking) to send the same > > message/sip > > signed with various certs that all correspond to me. how a UA would > > handle multiple message/sip bodies is unclear. > > This has been raised a couple of times in connection with the S/MIME > mechanism. Probably the simplest way of resolving this concern is to > recommend that each S/MIME body be signed with only one cert, and to > leave > any behavior for handling multiple certs undefined (or at best > suggesting > that the outermost signature be treated as the single cert for this > body). > Same for multiple 'message/sip' bodies. Help me out here; why would I want multiple certs for signing because of forking? > > > > > if I can replace the "outer" To and From headers, which tags > > do I use in a > > Replaces header? If I receive an authenticated reINVITE in the clear > > which operates on the "inside" To/From/Callid/tags, is this valid? > > > > This is good - I certainly wouldn't want someone to get the impression > that > tunneling a message means that we're trying to set up some sort of > second > session based on the encapsulated signaling, or something. We should > probably add a notice that the headers of an encapsulated 'message/sip' > body > are there for informational purposes and have no session semantics - > they > don't have dialog IDs or literally constitute some sort of tunneled > session > or what have you. Any session operations, including using things like > Replaces, target the 'outer' headers. The value of using a transport > protocol (in this instance SIP) to tunnel a SIP dialog between two fixed > endpoints has been discussed in the past (notably in SIMPLE recently), > and > not really found very useful - two fixed endpoints don't really need the > sorts of services that SIP provides; they might as well just trade MIME > bodies. Hmm, I think this one requires more thought. If you never actually use the inner headers, how does that prevent against an attack where an attacker modifies the outer ones in transit? Of course, there are legit cases where such things might happen (b2bua, for example); I suppose in these cases, a B2BUA shouldn't try to carry signatures through it though. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 12:12:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25615 for ; Wed, 30 Jan 2002 12:12:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10284 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:12:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07712; Wed, 30 Jan 2002 11:45:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07681 for ; Wed, 30 Jan 2002 11:45:08 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24619 for ; Wed, 30 Jan 2002 11:45:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UGjA6Y007601; Wed, 30 Jan 2002 11:45:10 -0500 (EST) Message-ID: <3C5822ED.CF3C112C@dynamicsoft.com> Date: Wed, 30 Jan 2002 11:44:29 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Christer Holmberg , Gonzalo Camarillo , Juha Heinanen , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP References: <15448.8222.86872.841578@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Jonathan Rosenberg writes: > > > > > > Christer Holmberg wrote: > > > > > > Hi, > > > > > > I do understand the reasons for using TCP, but why does it have to > be a > > > "MUST"? My node may never send messages so big, and it may be used > in a > > > network where it will never receive messages such big. > > > > > > Also, there may be nodes which will always communicate with a > specific > > > outbound proxy, so they may use a "static" SCTP association for > that. > > > > > > So, saying that nodes handling big messages shall use TCP (or > similar) > > > is ok, but making TCP mandatory for EVERY node is another issue... > > > > The problem is this. You can control what you can send, but not what > you > > will receive. If I send you a 2000 byte sip message, the spec says > that > > your proxy has to use TCP to send it to you. If you don't support > TCP, > > you won't get it. > > Jonathan, > > I'm having a real hard time understanding why it > is beneficial to the net if the UAC accepts the > TCP connection for a large response and then > immediately shuts down the connection. That seems > like an extra 6 messages to me. I'm assuming that > the UAC probably prefers UDP for some reason -- > like it or the proxy/UAS doesn't want to keep the > TCB around long term, etc. This is an excellent point, to be sure. Clearly, it becomes an issue as that message becomes larger. The question is, where do you draw the line? Apparently, a reasonable place to draw it as at the path MTU, since a host of other bad things begin to happen when you get there. As I point out in a previous note, the fact that there is a gradual worsening of UDP impact as messages increase in size is good for us from an adoption perspective; it means that since its not a major problem today, continued usage of UDP won't really massacre the net like http 1.0 did, but by the time the real problems role around, we'll be ready with TCP enabled UA. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 12:14:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25728 for ; Wed, 30 Jan 2002 12:14:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10356 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:14:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07439; Wed, 30 Jan 2002 11:42:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07410 for ; Wed, 30 Jan 2002 11:42:16 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24547 for ; Wed, 30 Jan 2002 11:42:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UGfp6Y007592; Wed, 30 Jan 2002 11:41:51 -0500 (EST) Message-ID: <3C582225.87BE6AE4@dynamicsoft.com> Date: Wed, 30 Jan 2002 11:41:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Christer Holmberg , Gonzalo Camarillo , Juha Heinanen , Michael Thomas , "Peterson, Jon" , sip@ietf.org Subject: Re: [Sip] Bis-06 and Deprecating UDP References: <3C581662.770A91EA@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Henning G. Schulzrinne" wrote: > > Also, despite various political correctness issues, UDP will work unless > you have a conflation of two things: > > - messages greater than (say) 1,500 bytes > - a NAT between the last-hop proxy and the UA > OR > - a highly lossy link (> 5% loss, say) > > (With 10% loss, the probability that a two-fragment packet won't make it > is about 19%, assuming independent losses.) Right; this is how we get backwards compatibility. I have no false assumptions that the world will all of a sudden have TCP endpoints once bis issues as an rfc; I suspect that it will be a LONG time until most endpoints support TCP, and that UDP with occassional fragmentation will continue to exist. Mandating TCP is really aimed at pushing UA in a direction where we can be sure that SIP becomes more "net friendly", and there are no awful surprises down the road when someone does decide to send that 1M SIP message. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 12:34:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26540 for ; Wed, 30 Jan 2002 12:34:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11457 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:34:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09987; Wed, 30 Jan 2002 12:07:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09959 for ; Wed, 30 Jan 2002 12:07:43 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25405 for ; Wed, 30 Jan 2002 12:07:41 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UH7s6Y007656; Wed, 30 Jan 2002 12:07:54 -0500 (EST) Message-ID: <3C582841.4ADB6518@dynamicsoft.com> Date: Wed, 30 Jan 2002 12:07:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: sip@ietf.org Subject: Re: [Sip] TLS is not a "transport" References: <15445.47813.551042.630855@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > The bis-06 draft improperly conflates TLS with a > transport protocol. This is incorret as it should > be obvious if you want to use TLS over SCTP. Any > conflation of this kind should be removed. HTTP > got this wrong too. Better would be to have some > sort of naming scheme which says: "SIP over > transport protected by security protocol". Are you arguing that instead of: sip:user@domain;transport=tls it should be: sip:user@domain;transport=sip-over-tcp-protected-by-tls? I think "tls" is better since its 3 bytes, compared to 29. I suppose what you really mean is that the text needs to indicate that TLS is not a transport, but we use the transport=tls parameter to indicate that the UAC needs to use TCP protected by TLS. Or are you arguing something else? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 12:36:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26591 for ; Wed, 30 Jan 2002 12:36:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11653 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:36:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08553; Wed, 30 Jan 2002 11:59:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08522 for ; Wed, 30 Jan 2002 11:59:12 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25143 for ; Wed, 30 Jan 2002 11:59:10 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UGxN6Y007635; Wed, 30 Jan 2002 11:59:23 -0500 (EST) Message-ID: <3C582642.46BA491A@dynamicsoft.com> Date: Wed, 30 Jan 2002 11:58:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: sip@ietf.org Subject: Re: [Sip] SIP and PKI References: <200201282102.NAA21096@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > bis-06 implies very strongly that SIP elements > should use PKI based authentication. This should > be removed. Hmm, I don't recall it saying you had to use PKI, just that S/MIME is a SHOULD. Honestly, I think its useless for encryption, but there is a VERY useful application for authentication using self-signed certs. That doesn't require a PKI, since you can self-generate keys. It seems to me, although I am admittedly an amateur at security protocols compared to many others on this list, that this gives us the only easily definable protection against the set of call hijacking attacks, where an passive attacker monitors my call, and injects faked BYE/INVITE with the proper dialog IDs. Assuming that, practically speaking, there is not ever going to be shared secrets between users, or a PKI, this is a pretty workable solution that does a lot of good with low cost, in terms of specification and availability of code to accomplish it. I wonder what other mechanisms you know of that are already defined, proven, and are easily integrated into SIP, and which work through SIP's multi-hop environment? Don't get me wrong, I'd love to see a ligher-weight approach to this, but I didn't see any off-the-shelfs for this. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 12:36:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26607 for ; Wed, 30 Jan 2002 12:36:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11667 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:37:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10105; Wed, 30 Jan 2002 12:09:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10071 for ; Wed, 30 Jan 2002 12:09:11 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25429 for ; Wed, 30 Jan 2002 12:09:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UH9F6Y007660; Wed, 30 Jan 2002 12:09:15 -0500 (EST) Message-ID: <3C582892.3DF44ED0@dynamicsoft.com> Date: Wed, 30 Jan 2002 12:08:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Juha Heinanen , "Peterson, Jon" , "'Cullen Jennings'" , sip@ietf.org Subject: Re: [Sip] Summary of TLS discussion References: <15448.10029.738978.751287@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > > > i forgot this one. since nats are nowadays everywhere, the > security > > > > solution MUST have a good nat story. otherwise sip will be dead > on > > > > arrival. > > > > > > IPsec working group is working on a standards track > > > way of doing this. Basically, ESP over UDP. > > > > How does that help? UDP can still fragment, of course, and all > > fragmentation is bad as far as a NAT is concerned. > > You can run TCP over IPsec too. Of course. I was merely questioning your response to Juha that the nat issues are being addressed by running ESP over UDP, and I was asking why that helps. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 12:37:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26633 for ; Wed, 30 Jan 2002 12:37:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11686 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:37:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10399; Wed, 30 Jan 2002 12:14:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10368 for ; Wed, 30 Jan 2002 12:14:37 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25729 for ; Wed, 30 Jan 2002 12:14:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UHEl6Y007675; Wed, 30 Jan 2002 12:14:47 -0500 (EST) Message-ID: <3C5829DE.8365B43C@dynamicsoft.com> Date: Wed, 30 Jan 2002 12:14:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] Comments on "unify" draft References: <200201251430.JAA73141@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > Jonathan wrote, in part: > > > Offer/Counter-Offer/Answer is a much cleaner solution than a > > > two-stage invite. > > > > I would still like to know in what ways an three-way exchange is > > cleaner? It is a few messages shorter, for sure. However, it cannot do > > anything the two two-pass cannot do, either functionally, or in terms > of > > latency. However, it adds complexity, since now we have two exchange > > mechanisms, and we will need to worry about how this interacts with > > 3pcc, how to signal which one is being used in which cases, and so on. > > The proposal eliminates all of that. > > I agree that a pair of two-way exchanges can do everything that a > three-way exchange can do, plus more. My comment above was that > the three-way exchange was better than the two-stage invite, and I > doubt there is any disagreement on that point. OK. > > One way in which the pair of two-way exchanges is significantly better > is that, in the 3-way exchange, the (UAS) response/counter-offer would > need to assign ports for all supported media streams, and just hope > that the UAC would not use most of them. I don't get it. If the UAS doesn't want a stream, then in either model it can be rejected in the first UAS->UAC message. > Jonathan also wrote: > > My main concern, and I am surprised its not yours as well, is timely > > completion of bis for 3gpp. To do that, we require parallelism. I > would > > very much like to last call bis-06 as issued, and we could do that > > shortly if this stuff stays out. In parallel with the last call > period, > > and iesg review, we can refine UPDATE/COMET, as this will take some > > time. > > Agree completely with the goal, and the concern. But I guess I am less > convinced that we can get three new I-Ds (one defining COMET/UPDATE, > second > for manyfolks, third for codec negotiation) through to RFCs in almost > zero > time. Past experience (which I know does not indicate future results) > is 30+ months. From a 3GPP view, is it better to have bis and not the > other three? Or all combined, but one or two months later? From what > I recall of TS24.228, the unify draft is already wrecking major havoc. This is a process issue which most definitely needs to be answered. I remain unclear on the schedule and constraints for the non-bis documents needed by 3g, including manyfolks, privacy, media-auth, sip-events, refer, replaces, and so on. It was my proposal to turn manyfolks into the new-COMET definition + the manyfolks usage, which would avoid another document. Since it already defines COMET + the manyfolks usage, its reasonably within the scope of the document. However, I concur that this is not a minor change and will take hard work to get it done for 3g timelines. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 12:39:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26694 for ; Wed, 30 Jan 2002 12:39:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11729 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:39:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09824; Wed, 30 Jan 2002 12:03:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09793 for ; Wed, 30 Jan 2002 12:03:25 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25252 for ; Wed, 30 Jan 2002 12:03:22 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0UH2jd14384; Wed, 30 Jan 2002 09:02:46 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAU01580; Wed, 30 Jan 2002 09:02:07 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA21964; Wed, 30 Jan 2002 09:02:37 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.10029.738978.751287@thomasm-u1.cisco.com> Date: Wed, 30 Jan 2002 09:02:37 -0800 (PST) To: Jonathan Rosenberg Cc: Michael Thomas , Juha Heinanen , "Peterson, Jon" , "'Cullen Jennings'" , sip@ietf.org Subject: Re: [Sip] Summary of TLS discussion In-Reply-To: <3C57A6A5.D501699F@dynamicsoft.com> References: <15446.65533.591315.693326@thomasm-u1.cisco.com> <3C57A6A5.D501699F@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > > > Michael Thomas wrote: > > > > Juha Heinanen writes: > > > Peterson, Jon writes: > > > > > > > - TLS has a good NAT traversal story. On several fronts > > (enumerated in a > > > > draft by Bernand Aboba), IPSec does not. > > > > > > i forgot this one. since nats are nowadays everywhere, the security > > > solution MUST have a good nat story. otherwise sip will be dead on > > > arrival. > > > > IPsec working group is working on a standards track > > way of doing this. Basically, ESP over UDP. > > How does that help? UDP can still fragment, of course, and all > fragmentation is bad as far as a NAT is concerned. You can run TCP over IPsec too. 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 daemon@optimus.ietf.org Wed Jan 30 12:51:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27249 for ; Wed, 30 Jan 2002 12:51:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12247 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:51:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11418; Wed, 30 Jan 2002 12:32:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11390 for ; Wed, 30 Jan 2002 12:32:51 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26456 for ; Wed, 30 Jan 2002 12:32:48 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UHRS6Y007707; Wed, 30 Jan 2002 12:27:28 -0500 (EST) Message-ID: <3C582CD8.11B4B5D7@dynamicsoft.com> Date: Wed, 30 Jan 2002 12:26:48 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sanjoy Sen CC: sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <933FADF5E673D411B8A30002A5608A0E01187874@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > > Hi, > > Following are some of the comments on the unify draft: > > 1) The draft proposes a Reason header to carry the reason codes. There's > also a sipfrag approach of carrying the an entire SIP request/response > as a new Mime type. Should there be a single approach and if they must > be different, what're the pros and cons of their usage? I was going for the simplest thing, since there seemed littl ebenefit to encapsulation as opposed to just including the headers and bodies within the provisional response, as needed. Is there a concrete reason why encapsulation is better? > > 2) Its not clear how the UA determines when to stop local ringing and > await early media. Pre-bis05 drafts mentioned using SDP within 183 to > indicate this to the UA. Does the UAC wait for a 1) new Offer, or 2) an > Answer, to stop any local ringing that might be taking place. I guess > the behavior would be same as for regular media, but it would help if > this is clarified. There is no difference between early media and media. Local alerting would presumably take place as a local implementation choice once a suitable provisional response (180, typically) has been received to indicate that the far end is, in fact, ringing. It would continue until the establishment of the session, early or otherwise. As a result, a 183 w/SDP finalizes the establishment of the session, and so that would stop any local ringback. I suppose that suspension of the session, with port zero, before the dialog is completed, would be a way to signal a UAC to revert back to local ringback, if that functionality was needed. > > 3) We support Rohan's proposal of using the new method UPDATE instead of > reusing the COMET, as the semantics are significantly different than > COMET. Seems to be a general consensus; I'd still like to hear from Bill on this topic in particular. > > 4) Another concern is, from 3GPP perspective, if this draft is the > replacement of manyfolks, then that calls for some major changes within > the 3GPP specs. I do not support inclusion of this in the bis, but the > bis should discuss these issues and refer to this draft as the solution > & this draft should be progressed towards the last call ASAP. I see little gain in having bis reference this document, that will introduce an unneeded dependency. I do agree that all of this, plus the recent route stuff, is going to be a lot of editing work for the folks maintaining 24.228. I certainly appreciate their work and patience in our struggle to get everything aligned and working for them. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 12:55:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27410 for ; Wed, 30 Jan 2002 12:55:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12295 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 12:55:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11517; Wed, 30 Jan 2002 12:34:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11486 for ; Wed, 30 Jan 2002 12:34:34 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26556 for ; Wed, 30 Jan 2002 12:34:30 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0UHXvL02274; Wed, 30 Jan 2002 09:33:57 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAU02312; Wed, 30 Jan 2002 09:33:26 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA21971; Wed, 30 Jan 2002 09:33:56 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.11908.316441.960887@thomasm-u1.cisco.com> Date: Wed, 30 Jan 2002 09:33:56 -0800 (PST) To: Jonathan Rosenberg Cc: Michael Thomas , sip@ietf.org Subject: Re: [Sip] TLS is not a "transport" In-Reply-To: <3C582841.4ADB6518@dynamicsoft.com> References: <15445.47813.551042.630855@thomasm-u1.cisco.com> <3C582841.4ADB6518@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg writes: > > > Michael Thomas wrote: > > > > The bis-06 draft improperly conflates TLS with a > > transport protocol. This is incorret as it should > > be obvious if you want to use TLS over SCTP. Any > > conflation of this kind should be removed. HTTP > > got this wrong too. Better would be to have some > > sort of naming scheme which says: "SIP over > > transport protected by security protocol". > > Are you arguing that instead of: > > sip:user@domain;transport=tls > > it should be: > > sip:user@domain;transport=sip-over-tcp-protected-by-tls? > > I think "tls" is better since its 3 bytes, compared to 29. > > I suppose what you really mean is that the text needs to indicate that > TLS is not a transport, but we use the transport=tls parameter to > indicate that the UAC needs to use TCP protected by TLS. > > Or are you arguing something else? I'm saying that your taxonomy is wrong. It should be something of the form: transport=tls.tcp or transport= tls.sctp then you can also have things like: transport=ipsec.tcp or transport=foo.udp Even if you don't like the ipsec part, we already need to consider tls over sctp. What's currently in bis makes adding that pretty kludgey. 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 daemon@optimus.ietf.org Wed Jan 30 13:04:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27585 for ; Wed, 30 Jan 2002 13:04:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13037 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 13:04:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11850; Wed, 30 Jan 2002 12:43:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11818 for ; Wed, 30 Jan 2002 12:43:10 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26936 for ; Wed, 30 Jan 2002 12:43:09 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0UHgdL12418; Wed, 30 Jan 2002 09:42:39 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAU02561; Wed, 30 Jan 2002 09:42:08 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA21977; Wed, 30 Jan 2002 09:42:38 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.12430.337296.839995@thomasm-u1.cisco.com> Date: Wed, 30 Jan 2002 09:42:38 -0800 (PST) To: "Peterson, Jon" Cc: sip@ietf.org Subject: [Sip] TLS, IPSec and consensus (bug #232) In-Reply-To: <70565611B164D511957A001083FCDD56CAAE68@VA02> References: <70565611B164D511957A001083FCDD56CAAE68@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit If you're going to gauge response to IPsec, you need to do the same thing for TLS. I haven't seen a whole lot of support for it either, and many have raised objections to its obesity. 3G isn't planning to use it on UA's; that does not bode well. The fact is, looking for support for either is not likely to get you very far. History has shown that ostrich behavior here is the preferred solution, even though that's not acceptable. What I see right now is that we will not have an interoperable standard for UA's. This is reality -- small footprint UA's will take the STRONGLY RECOMMENDED and ignore it in the blink of an eye. The SMIME recommendation is similarly a non-starter. The only thing that has *any* possibility of being implemented uniformly is digest and the minimal IPsec I've been talking about. Things that require hundreds of kb of code are going to flop on the very devices that need protection the most. Mike Peterson, Jon writes: > > I would like to suggest, based on the list discussion that has transpired to > date, that the chairs consider whether or not we have rough consensus in > favor of the current normative text on TLS and IPSec in bis06 22.3.1. > > The summary I sent out earlier today (along with Brian and Mike's summaries) > provides an account of the current state of the discussion. I believe that > the bis authors have been able to present a reasonable response to Mike's > strenuous objections. In any event, the issues are on the table, and those > who have debated these issues for months have essentially said their peace. > If there are any further arguments, or reflections on TLS vs. IPSec > transport vs. IPSec tunnel, from other members of the SIP community, let's > hear them now, by all means. Most respondents have indicated that they can > live with the text in bis06 today. > > I would also note that to date the reception of the proposed minimal IPSec > profile (ESP transport mode HMAC-MD5-NULL) has been lukewarm, I think. Some > respondents have expressed a preference for tunnel mode IPSec. The IESG also > seems to feel that some encryption algorithm, as well as a story about > keying, should be a part of an IPSec profile for SIP. While some encryption > algorithms has been mentioned on the list (like DES, as required by RFC > 2406), I haven't heard one that people sound entirely comfortable with. > > Ultimately, we all agree that we need to arrive at an IPSec profile for SIP > - I just don't believe that we need to solve this problem in bis. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 13:39:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28528 for ; Wed, 30 Jan 2002 13:39:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14652 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 13:39:41 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13530; Wed, 30 Jan 2002 13:17:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13500 for ; Wed, 30 Jan 2002 13:17:55 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27987 for ; Wed, 30 Jan 2002 13:17:52 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0UIHkb07051; Wed, 30 Jan 2002 13:17:46 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 12:17:45 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE6E@VA02> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" Cc: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] ambiguities with S/MIME Date: Wed, 30 Jan 2002 12:17:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The question is really how you 'use' the inner headers. Most headers don't have any end-to-end semantic aside from the establishment of a dialog ID. If the headers are merely informational (like the Subject header), then I think it's pretty clear how you'd use them informationally: the client displays the 'inner' one to the end user. I put in one example of inserting a different From header in an encrypted body to provide rudimentary privacy; we don't provide that so that you can check and make sure that the tag on the From header is the same, but because the outer header says 'Anonymous' and the inner one says your real name. Again, a UA could display the 'inner' head to the user, but use the 'outer' one for all protocol activity. This is something we need to make explicit, I agree. On the multiple signatures thing, I agree there aren't very many obvious reasons for signing a message with multiple identities (any mental problems aside). Maybe if the originating user suspect that they were known by different identities to different potential recipients of the request (not sure why that would be, admittedly), they might want to sign the message multiple times. Simplest answer is to limit to one signature, I think. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, January 30, 2002 8:52 AM > To: Peterson, Jon > Cc: 'Rohan Mahy'; sip@ietf.org > Subject: Re: [Sip] ambiguities with S/MIME > > > > > "Peterson, Jon" wrote: > > > > > > it might be useful (especially with forking) to send the same > > > message/sip > > > signed with various certs that all correspond to me. how > a UA would > > > handle multiple message/sip bodies is unclear. > > > > This has been raised a couple of times in connection with the S/MIME > > mechanism. Probably the simplest way of resolving this concern is to > > recommend that each S/MIME body be signed with only one cert, and to > > leave > > any behavior for handling multiple certs undefined (or at best > > suggesting > > that the outermost signature be treated as the single cert for this > > body). > > Same for multiple 'message/sip' bodies. > > Help me out here; why would I want multiple certs for signing > because of > forking? > > > > > > > > > if I can replace the "outer" To and From headers, which tags > > > do I use in a > > > Replaces header? If I receive an authenticated reINVITE > in the clear > > > which operates on the "inside" To/From/Callid/tags, is this valid? > > > > > > > This is good - I certainly wouldn't want someone to get the > impression > > that > > tunneling a message means that we're trying to set up some sort of > > second > > session based on the encapsulated signaling, or something. We should > > probably add a notice that the headers of an encapsulated > 'message/sip' > > body > > are there for informational purposes and have no session semantics - > > they > > don't have dialog IDs or literally constitute some sort of tunneled > > session > > or what have you. Any session operations, including using > things like > > Replaces, target the 'outer' headers. The value of using a transport > > protocol (in this instance SIP) to tunnel a SIP dialog > between two fixed > > endpoints has been discussed in the past (notably in SIMPLE > recently), > > and > > not really found very useful - two fixed endpoints don't > really need the > > sorts of services that SIP provides; they might as well > just trade MIME > > bodies. > > Hmm, I think this one requires more thought. If you never actually use > the inner headers, how does that prevent against an attack where an > attacker modifies the outer ones in transit? Of course, there > are legit > cases where such things might happen (b2bua, for example); I > suppose in > these cases, a B2BUA shouldn't try to carry signatures through it > though. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 14:00:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29201 for ; Wed, 30 Jan 2002 14:00:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16265 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 14:00:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14731; Wed, 30 Jan 2002 13:41:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14706 for ; Wed, 30 Jan 2002 13:41:35 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28592 for ; Wed, 30 Jan 2002 13:41:33 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0UIekI23671; Wed, 30 Jan 2002 10:40:48 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAU04461; Wed, 30 Jan 2002 10:40:15 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA21984; Wed, 30 Jan 2002 10:40:45 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.15917.784802.602754@thomasm-u1.cisco.com> Date: Wed, 30 Jan 2002 10:40:45 -0800 (PST) To: "Peterson, Jon" Cc: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] ambiguities with S/MIME In-Reply-To: <70565611B164D511957A001083FCDD56CAAE65@VA02> References: <70565611B164D511957A001083FCDD56CAAE65@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit A UA always has the option of speaking end to end which completely mitigates the MITM problem. Since SMIME is imperfect, its unintended consequences are not well understood, and the actual need for e2e transport is questionable vs the end to middle problem where there is pretty clear evidence of need (cf the privacy thread), I think that SMIME should be removed from the bis draft and taken up later. It's removal right now would not prevent anybody with experimenting with its use. Normative text could do a great deal of damage if it is wrong. Considering how late this has been added, I will without hesitation say that the 06 text for SMIME will get many things wrong; this is just a trusim of computer engineering. Mike Peterson, Jon writes: > > Our decision to include more substantial text for S/MIME usage in bis06 was > motivated by the absence of the PGP mechanism that appeared in RFC 2543, and > by a set of known threats connected to the inspection or modification of > bodies by intermediaries. Let's face it - not too many protocols grant as > many opportunities as SIP for men-in-the-proverbial-middle to muck with > messages. There was a general feeling that securing things end-to-end should > happen at the level of MIME bodies, and S/MIME is sort of the natural (read: > only) choice. We feared that without any mechanism for body security (or > some mere lip-service along the lines of the bis05 text) it could be argued > that the SIP standard doesn't provide a reasonable overall security story. > > On these grounds, despite the fact that the text undoubtedly has some > blemishes, I think we should try to go forward with it. I think we can > address the specific ambiguities you raise below without terrific effort > (some notes below). I think our best bet is to get this text into as good a > shape as we can and to go forward with it. We'd definitely appreciate any > further comments along these lines. > > Jon Peterson > NeuStar, Inc. > > > -----Original Message----- > > From: Rohan Mahy [mailto:rmahy@cisco.com] > > Sent: Tuesday, January 29, 2002 6:01 PM > > To: sip@ietf.org > > Subject: [Sip] ambiguities with S/MIME > > > > > [snip] > > example ambiguities: > > > > it might be useful (especially with forking) to send the same > > message/sip > > signed with various certs that all correspond to me. how a UA would > > handle multiple message/sip bodies is unclear. > > This has been raised a couple of times in connection with the S/MIME > mechanism. Probably the simplest way of resolving this concern is to > recommend that each S/MIME body be signed with only one cert, and to leave > any behavior for handling multiple certs undefined (or at best suggesting > that the outermost signature be treated as the single cert for this body). > Same for multiple 'message/sip' bodies. > > > > > if I can replace the "outer" To and From headers, which tags > > do I use in a > > Replaces header? If I receive an authenticated reINVITE in the clear > > which operates on the "inside" To/From/Callid/tags, is this valid? > > > > This is good - I certainly wouldn't want someone to get the impression that > tunneling a message means that we're trying to set up some sort of second > session based on the encapsulated signaling, or something. We should > probably add a notice that the headers of an encapsulated 'message/sip' body > are there for informational purposes and have no session semantics - they > don't have dialog IDs or literally constitute some sort of tunneled session > or what have you. Any session operations, including using things like > Replaces, target the 'outer' headers. The value of using a transport > protocol (in this instance SIP) to tunnel a SIP dialog between two fixed > endpoints has been discussed in the past (notably in SIMPLE recently), and > not really found very useful - two fixed endpoints don't really need the > sorts of services that SIP provides; they might as well just trade MIME > bodies. > > > obviously some headers shouldn't get replaced: > > Via, Route, Record-Route are there any more? > > There is some text in 21.4.1 that speaks to the fact that some headers can > be modified in transit without this constituting a breach in integrity. > Realistically, this text should be popped up the stack to 21.4, since it > applies to both types of tunneling. All of these headers are mentioned > there. > > > > > thoughts? > > > > 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 daemon@optimus.ietf.org Wed Jan 30 14:14:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29805 for ; Wed, 30 Jan 2002 14:14:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17394 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 14:14:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15381; Wed, 30 Jan 2002 13:53:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15246 for ; Wed, 30 Jan 2002 13:53:04 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28988 for ; Wed, 30 Jan 2002 13:53:02 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0UIonb31434; Wed, 30 Jan 2002 12:50:49 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 12:50:49 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE70@VA02> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" , Michael Thomas Cc: sip@ietf.org Subject: RE: [Sip] Bis-06 and Deprecating UDP Date: Wed, 30 Jan 2002 12:50:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In the spec today, Digest is used for one-way authentication and replay protection, which do indeed prevent a reasonable class of attacks. If I look at the functions that I think I get out of TLS, they include: - Allows a proxy server to authenticate itself to a user agent (with a certificate). The Digest alternative, in which the server would authenticate itself to a user with a shared secret, has always seemed a little kludgy to me (and there are some fixes we'd need in the spec to get there), and moreover it assumes a pre-existing trust relationship between user and server which the PKI-based method does not. I think this is quite relevant to the matter of what works for large deployments. - Allows confidentiality between the user agent and the proxy server. Obviously Digest isn't going to get us here. A few people in this thread have asserted that confidentiality in the first hop isn't important (basically arguing for walled-garden SIP networks), but there are a number of attacks of which only arise if the attacker can inspect these messages. - Allows integrity between the user agent and the proxy server. Digest can probably get us here, with some enhancements. Again, this would require some work in the spec. That hop-by-hop integrity provided by TLS gis also a little better understood that end-to-middle integrity Digest would provide (which may require canonicalization of headers, and it might not be clear which headers do and do not require integrity). Of course, Digest integrity could also be used just for the first hop. I think there needs to be some mechanism, at a reasonable normative strength, that provides some of the services above in baseline SIP. I'd rather not punt on those features. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, January 29, 2002 11:31 PM > To: Michael Thomas > Cc: Peterson, Jon; sip@ietf.org > Subject: Re: [Sip] Bis-06 and Deprecating UDP > > > > > Michael Thomas wrote: > > [snip] > > It's incomplete because a perfectly valid transport > > mode -- UDP -- doesn't have a perfectly valid MUST > > IMPLEMENT security scheme. What you're saying is > > "if you want security, use TLS". That is not > > helpful for when you use UDP. > > Agreed, it is not. IMHO, we need a non-transport oriented solution as > the baseline for UA to proxy security functions. I believe > that baseline > is digest. While it certainly has many weaknesses that are well known, > it is better than nothing, and has the benefit of being implementable > and solving a reasonable class of attacks. TLS is better for smaller > deployments, where the scale issues are not so bad that you > can pay for > the persistent connections. IPSec is not likely to be any better in > terms of scale, since both have the same state issues. Once you move > away from persistent connections, TLS suffers heavily from expensive > setups that you will effectively repeat for each call, increasing > latency and overhead. IPSec is similar; I dislike its keying > mechanisms > as well, but let us not dive into that, since its not really important > for this point. So, since both TLS and IPSec have fatal flaws > for large > deployments, digest is preferred as the only broadly workable solution > there. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 14:28:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00158 for ; Wed, 30 Jan 2002 14:28:37 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18022 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 14:28:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16720; Wed, 30 Jan 2002 14:05:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16689 for ; Wed, 30 Jan 2002 14:05:33 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29369 for ; Wed, 30 Jan 2002 14:05:31 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0UJ5Wb32149; Wed, 30 Jan 2002 13:05:32 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 13:05:32 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE72@VA02> From: "Peterson, Jon" To: "'Rosen, Brian'" , "Peterson, Jon" , sip@ietf.org Subject: RE: [Sip] TLS, IPSec and consensus (bug #232) Date: Wed, 30 Jan 2002 13:05:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Brian is right about the fact that both IPSec and TLS work only for the respective architectures to which they are applicable. I agree that there is a critical need for an IPSec profile - I think the only real question is whether or not it needs to be in bis in order for the security story in bis to be complete. I don't know of any litmus test for this. I do know that I got the impression that punting on confidentiality and keying wouldn't be acceptable. I think we have the luxury to take our time and do IPSec right - not to cram something into bis hastily - because our existing security story, while it has limitations, covers many of the important threats. One specific further note below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Wednesday, January 30, 2002 5:30 AM > To: 'Peterson, Jon'; sip@ietf.org > Subject: RE: [Sip] TLS, IPSec and consensus (bug #232) > [snip] > > I'd like to see a distinction between what a UA > should/must do and what a PS should/must do. > I'd like the UA to not have to should/must > either TLS or IPsec, but rather be content > with Digest. I'd like to see some words that > basically say that PS intended to work > within a domain must implement IPSec, and > PSs intended to work cross domain must implement > TLS and both should implement both. Harkening back to Rohan's mail, I think there are in fact multiple IPSec 'worlds' that people are interested in here. The ESP transport mode 'world' could look pretty similar to TLS (provided it had some sort of confidentiality and key exchange, and the application-binding stuff were understood). The ESP tunnel mode 'world', based on security gateways, has very different properties, I think. The requirements for support in various SIP network elements of these two 'worlds' would be different. > > Brian > > > -----Original Message----- > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > > Sent: Wednesday, January 30, 2002 2:25 AM > > To: sip@ietf.org > > Subject: [Sip] TLS, IPSec and consensus (bug #232) > > > > > > > > I would like to suggest, based on the list discussion that > > has transpired to > > date, that the chairs consider whether or not we have rough > > consensus in > > favor of the current normative text on TLS and IPSec in > bis06 22.3.1. > > > > The summary I sent out earlier today (along with Brian and > > Mike's summaries) > > provides an account of the current state of the discussion. I > > believe that > > the bis authors have been able to present a reasonable > > response to Mike's > > strenuous objections. In any event, the issues are on the > > table, and those > > who have debated these issues for months have essentially > > said their peace. > > If there are any further arguments, or reflections on TLS vs. IPSec > > transport vs. IPSec tunnel, from other members of the SIP > > community, let's > > hear them now, by all means. Most respondents have indicated > > that they can > > live with the text in bis06 today. > > > > I would also note that to date the reception of the proposed > > minimal IPSec > > profile (ESP transport mode HMAC-MD5-NULL) has been lukewarm, > > I think. Some > > respondents have expressed a preference for tunnel mode > > IPSec. The IESG also > > seems to feel that some encryption algorithm, as well as a > story about > > keying, should be a part of an IPSec profile for SIP. While > > some encryption > > algorithms has been mentioned on the list (like DES, as > > required by RFC > > 2406), I haven't heard one that people sound entirely > > comfortable with. > > > > Ultimately, we all agree that we need to arrive at an IPSec > > profile for SIP > > - I just don't believe that we need to solve this problem in bis. > > > > Jon Peterson > > NeuStar, Inc. > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > > This e-mail and any attachments are confidential. If you are not the > intended recipient, please notify us immediately by reply > e-mail and then > delete this message from your system. Do not copy this e-mail or any > attachment, use the contents for any purposes, or disclose > the contents to > any other person: to do so could be a breach of confidence. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 15:09:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01178 for ; Wed, 30 Jan 2002 15:09:38 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20870 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 15:09:40 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19772; Wed, 30 Jan 2002 14:54:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19740 for ; Wed, 30 Jan 2002 14:54:36 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00841 for ; Wed, 30 Jan 2002 14:54:34 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0UJs5L16320; Wed, 30 Jan 2002 11:54:05 -0800 (PST) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACK39738 (AUTH rmahy); Wed, 30 Jan 2002 11:54:05 -0800 (PST) Message-Id: <200201301954.ACK39738@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com with HTTP/1.0; Wed, 30 Jan 2002 11:54:40 -0800 Date: Wed, 30 Jan 2002 11:54:40 -0800 From: Rohan Mahy Subject: RE: [Sip] ambiguities with S/MIME To: Michael Thomas Cc: "Peterson, Jon" , "'Rohan Mahy'" , sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >From: Michael Thomas > >A UA always has the option of speaking end to end >which completely mitigates the MITM problem. Not so in the presence of NATs, with which many of us are afflicted. While I tend to agree that SMIME would be better described in another document, I still think that we should be prepared to give a credible description of *a way* to use it end-to-end. [Since Jon went to great pains to avoid the PKI minefield here.] The IESG may request the inclusion of such a description in bis. We should try to identify specific problems and ambiguities with what Jon proposed, and preferably *solutions* and proposed clarifications. If we discover insurmountable technical obstacles, then we can explain the specifics to the IESG, but at the moment we just have general objections and a few specific ambiguities that Jon is trying to address. thanks, -rohan >Since >SMIME is imperfect, its unintended consequences >are not well understood, and the actual need for >e2e transport is questionable vs the end to middle >problem where there is pretty clear evidence of >need (cf the privacy thread), I think that SMIME >should be removed from the bis draft and taken up >later. It's removal right now would not prevent >anybody with experimenting with its use. Normative >text could do a great deal of damage if it is >wrong. Considering how late this has been added, I >will without hesitation say that the 06 text for >SMIME will get many things wrong; this is just a >trusim of computer engineering. > > Mike > >Peterson, Jon writes: > > > > Our decision to include more substantial text for S/MIME usage in bis06 was > > motivated by the absence of the PGP mechanism that appeared in RFC 2543, and > > by a set of known threats connected to the inspection or modification of > > bodies by intermediaries. Let's face it - not too many protocols grant as > > many opportunities as SIP for men-in-the-proverbial- middle to muck with > > messages. There was a general feeling that securing things end-to-end should > > happen at the level of MIME bodies, and S/MIME is sort of the natural (read: > > only) choice. We feared that without any mechanism for body security (or > > some mere lip-service along the lines of the bis05 text) it could be argued > > that the SIP standard doesn't provide a reasonable overall security story. > > > > On these grounds, despite the fact that the text undoubtedly has some > > blemishes, I think we should try to go forward with it. I think we can > > address the specific ambiguities you raise below without terrific effort > > (some notes below). I think our best bet is to get this text into as good a > > shape as we can and to go forward with it. We'd definitely appreciate any > > further comments along these lines. > > > > Jon Peterson > > NeuStar, Inc. > > > > > -----Original Message----- > > > From: Rohan Mahy [mailto:rmahy@cisco.com] > > > Sent: Tuesday, January 29, 2002 6:01 PM > > > To: sip@ietf.org > > > Subject: [Sip] ambiguities with S/MIME > > > > > > > > [snip] > > > example ambiguities: > > > > > > it might be useful (especially with forking) to send the same > > > message/sip > > > signed with various certs that all correspond to me. how a UA would > > > handle multiple message/sip bodies is unclear. > > > > This has been raised a couple of times in connection with the S/MIME > > mechanism. Probably the simplest way of resolving this concern is to > > recommend that each S/MIME body be signed with only one cert, and to leave > > any behavior for handling multiple certs undefined (or at best suggesting > > that the outermost signature be treated as the single cert for this body). > > Same for multiple 'message/sip' bodies. > > > > > > > > if I can replace the "outer" To and From headers, which tags > > > do I use in a > > > Replaces header? If I receive an authenticated reINVITE in the clear > > > which operates on the "inside" To/From/Callid/tags, is this valid? > > > > > > > This is good - I certainly wouldn't want someone to get the impression that > > tunneling a message means that we're trying to set up some sort of second > > session based on the encapsulated signaling, or something. We should > > probably add a notice that the headers of an encapsulated 'message/sip' body > > are there for informational purposes and have no session semantics - they > > don't have dialog IDs or literally constitute some sort of tunneled session > > or what have you. Any session operations, including using things like > > Replaces, target the 'outer' headers. The value of using a transport > > protocol (in this instance SIP) to tunnel a SIP dialog between two fixed > > endpoints has been discussed in the past (notably in SIMPLE recently), and > > not really found very useful - two fixed endpoints don't really need the > > sorts of services that SIP provides; they might as well just trade MIME > > bodies. > > > > > obviously some headers shouldn't get replaced: > > > Via, Route, Record-Route are there any more? > > > > There is some text in 21.4.1 that speaks to the fact that some headers can > > be modified in transit without this constituting a breach in integrity. > > Realistically, this text should be popped up the stack to 21.4, since it > > applies to both types of tunneling. All of these headers are mentioned > > there. > > > > > > > > thoughts? > > > > > > 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 daemon@optimus.ietf.org Wed Jan 30 15:13:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01278 for ; Wed, 30 Jan 2002 15:13:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20983 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 15:13:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19643; Wed, 30 Jan 2002 14:51:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19612 for ; Wed, 30 Jan 2002 14:51:55 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00738 for ; Wed, 30 Jan 2002 14:51:52 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0UJpab09449; Wed, 30 Jan 2002 14:51:36 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 13:51:36 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE73@VA02> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" , "Peterson, Jon" Cc: "'Michael Thomas'" , Juha Heinanen , "Rosen, Brian" , "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] TLS section Date: Wed, 30 Jan 2002 13:51:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org One tiny note below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, January 29, 2002 11:17 PM > To: Peterson, Jon > Cc: 'Michael Thomas'; Juha Heinanen; Rosen, Brian; 'Dean Willis'; > sip@ietf.org > Subject: Re: [Sip] TLS section > > [snip] > > > Arguably, given that there are cases where IPSec is right and > where TLS > is right, you should make both of them MUST to provide > interoperability. > However, I think I would be visciously beaten by many folks for > proposing that. > [snip] > > The main issue will arise cross-domain. In those cases, I > would probably select TLS over IPSec, primarily because I would expect > the proxy application would need to know who it was talking with. > -Jonathan R. While I'll come short of aggravated assault, I think the possibiliy of TLS over IPSec is one of the reasons why we need to give some more thought to interoperability of networks using these different security solutions. This begs a lot of questions about how TLS would interact with transport mode as opposed to tunnel mode IPSec. We'd probably want to avoid TLS over IPSec if we can. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 15:25:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01569 for ; Wed, 30 Jan 2002 15:25:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21327 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 15:25:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20732; Wed, 30 Jan 2002 15:06:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20701 for ; Wed, 30 Jan 2002 15:06:04 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01055 for ; Wed, 30 Jan 2002 15:05:57 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.87]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0UK676Y008282; Wed, 30 Jan 2002 15:06:08 -0500 (EST) Message-ID: <3C585207.81722D63@dynamicsoft.com> Date: Wed, 30 Jan 2002 15:05:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Rohan Mahy'" , sip@ietf.org Subject: Re: [Sip] ambiguities with S/MIME References: <70565611B164D511957A001083FCDD56CAAE6E@VA02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > The question is really how you 'use' the inner headers. Most headers > don't > have any end-to-end semantic aside from the establishment of a dialog > ID. Well, there are things like CSeq for sequencing. OK, so here is an example of what I mean. A sends B an INVITE, with a signed mime body. They sent with CSeq 5. An attacker intercepts, modifies the outer CSeq to 500, changing nothing else, and keeping the signature. This arrives at the UAS. The UAS still uses the outer headers, so it updates the remote CSeq to 500. Now, the UAS will reject any subsequent messages from the UAC, since they will have a CSeq that is too low. This is similar to a registration attack which I think James pointed out. I suppose the same argument I made there could apply here, which is, that the middleman could just instead through away the packet with the same result, and that is an insurmountable attack. However, the point is really that it is not obvious that there are no security consequences with using some of the non-informational headers from the outside. I don't think this is a hard problem to fix, we just need to think it through and make sure we know whcih ones are the right ones to use, and if there is a general way to describe it. > On the multiple signatures thing, I agree there aren't very many obvious > reasons for signing a message with multiple identities (any mental > problems > aside). Maybe if the originating user suspect that they were known by > different identities to different potential recipients of the request > (not > sure why that would be, admittedly), they might want to sign the message > multiple times. Simplest answer is to limit to one signature, I think. Agreed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 16:52:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03022 for ; Wed, 30 Jan 2002 16:52:35 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25133 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 16:52:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24586; Wed, 30 Jan 2002 16:35:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24554 for ; Wed, 30 Jan 2002 16:35:07 -0500 (EST) Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02674 for ; Wed, 30 Jan 2002 16:35:03 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #47837) id <0GQR00801T985E@firewall.wcom.com> for sip@ietf.org; Wed, 30 Jan 2002 21:34:20 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (PMDF V5.2-33 #47837) with ESMTP id <0GQR00750T97PD@firewall.wcom.com>; Wed, 30 Jan 2002 21:34:20 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GQR00301T8XUF@pmismtp03.wcomnet.com>; Wed, 30 Jan 2002 21:34:19 +0000 (GMT) Received: from ajohnston ([166.44.57.94]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GQR000G9T8SUY@pmismtp03.wcomnet.com>; Wed, 30 Jan 2002 21:34:06 +0000 (GMT) Date: Wed, 30 Jan 2002 15:33:52 -0600 From: Alan Johnston Subject: RE: [Sip] solving early media, HERFP, and unifying manyfolks In-reply-to: <3C582CD8.11B4B5D7@dynamicsoft.com> To: "'Jonathan Rosenberg'" , "'Sanjoy Sen'" Cc: sip@ietf.org Message-id: <00e001c1a9d5$d1216740$3c202aa6@ajohnston> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan, I'd like to try to focus the discussion on the issue of the moment (literally) relating to bis. While more discussion is needed before we can reach consensus on your proposal, we need to agree right now if we want to make the one change to bis to allow the possibility of this proposal. Right now, bis says that a 200 OK MUST have SDP, either an answer if the INVITE had an offer, or an offer if the INVITE did not, in which case the answer will be in the ACK. We would need to change bis to allow for the offer/answer to take place outside of the INVITE/200/ACK exchange in an extension to SIP. I think it would be good to make this change, keeping the existing offer/answer model but adding a statement that extensions may define new ways of making offers or answers which could take the place of the bis discussion. Perhaps this change is needed even for manyfolks COMET not to contradict bis? Can we come to consensus on the list to agree to this change? Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com Jonathan Rosenberg wrote: > Sent: Wednesday, January 30, 2002 11:27 AM > To: Sanjoy Sen > Cc: sip@ietf.org > Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks > > > > > Sanjoy Sen wrote: > > > > Hi, > > > > Following are some of the comments on the unify draft: > > > > 1) The draft proposes a Reason header to carry the reason codes. > > There's also a sipfrag approach of carrying the an entire SIP > > request/response as a new Mime type. Should there be a > single approach > > and if they must be different, what're the pros and cons of their > > usage? > > I was going for the simplest thing, since there seemed littl > ebenefit to encapsulation as opposed to just including the > headers and bodies within the provisional response, as needed. > > Is there a concrete reason why encapsulation is better? > > > > > 2) Its not clear how the UA determines when to stop local > ringing and > > await early media. Pre-bis05 drafts mentioned using SDP > within 183 to > > indicate this to the UA. Does the UAC wait for a 1) new > Offer, or 2) > > an Answer, to stop any local ringing that might be taking place. I > > guess the behavior would be same as for regular media, but it would > > help if this is clarified. > > There is no difference between early media and media. Local > alerting would presumably take place as a local > implementation choice once a suitable provisional response > (180, typically) has been received to indicate that the far > end is, in fact, ringing. It would continue until the > establishment of the session, early or otherwise. As a > result, a 183 w/SDP finalizes the establishment of the > session, and so that would stop any local ringback. > > I suppose that suspension of the session, with port zero, > before the dialog is completed, would be a way to signal a > UAC to revert back to local ringback, if that functionality > was needed. > > > > > > 3) We support Rohan's proposal of using the new method > UPDATE instead > > of reusing the COMET, as the semantics are significantly different > > than COMET. > > Seems to be a general consensus; I'd still like to hear from > Bill on this topic in particular. > > > > > 4) Another concern is, from 3GPP perspective, if this draft is the > > replacement of manyfolks, then that calls for some major changes > > within the 3GPP specs. I do not support inclusion of this > in the bis, > > but the bis should discuss these issues and refer to this > draft as the > > solution & this draft should be progressed towards the last > call ASAP. > > I see little gain in having bis reference this document, that > will introduce an unneeded dependency. > > I do agree that all of this, plus the recent route stuff, is > going to be a lot of editing work for the folks maintaining > 24.228. I certainly appreciate their work and patience in our > struggle to get everything aligned and working for them. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 17:16:06 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03511 for ; Wed, 30 Jan 2002 17:16:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA26416 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 17:16:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25924; Wed, 30 Jan 2002 17:01:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25891 for ; Wed, 30 Jan 2002 17:01:09 -0500 (EST) Received: from radvpost.us.radvision.com ([38.150.216.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03258 for ; Wed, 30 Jan 2002 17:01:05 -0500 (EST) Received: by RADVPOST with Internet Mail Service (5.5.2650.21) id ; Wed, 30 Jan 2002 16:59:13 -0500 Message-ID: <0D5BBF5D638DD4119E3400508BD94945AE4A58@RADVPOST> From: Sasha Ruditsky To: "'sip@ietf.org'" Subject: RE: [Sip] The right solution to sip routing Date: Wed, 30 Jan 2002 16:59:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonatan I just would like to get clarification on one thing: You talk about "ability to finally discard the maddr parameter in the URI". Robert writes "the uses of maddr that have evolved to try to get around some of the strict routing problems will be deprecated." More specifically: Will the use of maddr to specify the multicast address be depricated or not. Thanks Sasha -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, January 30, 2002 11:10 AM To: Jo Hornsby Cc: Robert Sparks; sip@ietf.org Subject: Re: [Sip] The right solution to sip routing Thanks for the support, Jo. I'd also like to say a few words on this. After years of changes and fixes and patches and modifications, I *finally* feel like we have it right. I am certain that the ideal behavior in the note Robert sent is the right one. The only ugliness around the mechanism surrounds the requirement for mucking with the route set in order to handle downstream strict routers; this actually will go away as proxies and UAs get upgraded to bis. It is my hope and expectation that this aspect of the specification would be removed when we rev to draft, and it was part of our goals to define a mechanism which would not "leave a mess forever", allowing the interim mechanisms to only get invoked when needed. An important benefit of the mechanism, which Robert mentions, is the ability to finally discard the maddr parameter in the URI. maddr is really the earliest legacy of our attempts at source routing. I think it is clear that it should be discarded when you think about things in terms of names, addresses, and routes. The URI is a name/address, but definitely NOT a route. However, maddr is clearly a parameter for routing, and thus does not belong in the URI. We needed it because initially, we needed a way for a proxy to create a URL that BOTH indicated the final destination AND the hop to get there. By formally separating these now, as it should be, the need for maddr disappears. This provides a nice resolution of the various problems we have found in the interpretation of transport and port in the URI when maddr was present, in addition to proxy processing logic in the presence of maddr in the r-uri. THis causes confusion since it effectively presents two independent routing guidelines - the URI, and the Route headers, and there are precedence issues which are hard to resolve. The proposal helps resolve them by making sure there is one mechanism for routing. The mechanism also makes the way much easier for a formal definition of the Path header. Now, it becomes just like record-route - it represents a hop. The difference is only one of scope. The UA uses it to learn of pre-loaded routes to a particular domain, and the registrar uses it to learn of pre-loaded routes to a client. A proxy inserts one when it wishes to be on a pre-loaded route to that domain, or in the path of calls from that domain back to the UA. The scope of it depends on the message its carried in; for REGISTER, its scoped to the lifetime of the registration. But, it seems like it would even be useful to allow Path in something like OPTIONS, which would allow a UA to learn of preloaded routes to a domain without having to register to that domain. 3gpp can elect not to use it, but it would allow for a more general "pre-loaded route discovery" tool which could be used without binding outgoing calls to a registration. I'll send a separate note with an example flow of how I think it should work based on this new mechanism. Much thanks to Robert for doing a tremendous amount of working in getting us from where we were to where we are now. Arguably the hardest and most important problem in SIP is now licked! -Jonathan R. Jo Hornsby wrote: > > > Folks - > [...] > > Voila! Everything works very nicely. > > Wow. > > Very good. > > I'm 'pressed that you managed to weave such magic given > the long legacy of specifications/implementations/ > recommendations in a backwardly-compatible way, and still > get near as damnit ideal behaviour. > > Certainly gets my vote. > > - Jo. > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 17:44:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04010 for ; Wed, 30 Jan 2002 17:44:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA27832 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 17:44:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26680; Wed, 30 Jan 2002 17:26:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26651 for ; Wed, 30 Jan 2002 17:26:30 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03705 for ; Wed, 30 Jan 2002 17:26:26 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0UMPHb14002; Wed, 30 Jan 2002 17:25:17 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 16:25:17 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE79@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" , Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] TLS is not a "transport" Date: Wed, 30 Jan 2002 16:25:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm not sure how a SIP application would know whether or not SIP is running over IPSec in some architectures. Especially problematic under your proposal are cases in which a SIP application sends a Via header in a request indicating that the current transport is UDP/IPSec, but this message passes through a security gateway, and by the time it reaches the next hop it has in fact become over UDP/IP (and this seems to be one of several related cases). I'm also not sure what we would get out of this (then again, nor am I entirely sure we get out of having transport=tls rather than just transport=tcp - but that's a whole different kettle of fish). Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, January 30, 2002 9:34 AM > To: Jonathan Rosenberg > Cc: Michael Thomas; sip@ietf.org > Subject: Re: [Sip] TLS is not a "transport" > > > Jonathan Rosenberg writes: > > > > > > Michael Thomas wrote: > > > > > > The bis-06 draft improperly conflates TLS with a > > > transport protocol. This is incorret as it should > > > be obvious if you want to use TLS over SCTP. Any > > > conflation of this kind should be removed. HTTP > > > got this wrong too. Better would be to have some > > > sort of naming scheme which says: "SIP over > > > transport protected by security protocol". > > > > Are you arguing that instead of: > > > > sip:user@domain;transport=tls > > > > it should be: > > > > sip:user@domain;transport=sip-over-tcp-protected-by-tls? > > > > I think "tls" is better since its 3 bytes, compared to 29. > > > > I suppose what you really mean is that the text needs to > indicate that > > TLS is not a transport, but we use the transport=tls parameter to > > indicate that the UAC needs to use TCP protected by TLS. > > > > Or are you arguing something else? > > I'm saying that your taxonomy is wrong. It should > be something of the form: > > transport=tls.tcp or transport= tls.sctp > > then you can also have things like: > > transport=ipsec.tcp or transport=foo.udp > > Even if you don't like the ipsec part, we already > need to consider tls over sctp. What's currently in > bis makes adding that pretty kludgey. > > 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 daemon@optimus.ietf.org Wed Jan 30 17:49:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04098 for ; Wed, 30 Jan 2002 17:49:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA28041 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 17:49:34 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27469; Wed, 30 Jan 2002 17:32:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27362 for ; Wed, 30 Jan 2002 17:32:34 -0500 (EST) Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03806 for ; Wed, 30 Jan 2002 17:32:30 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g0UMWIb10219; Wed, 30 Jan 2002 16:32:19 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 16:32:18 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE7A@VA02> From: "Peterson, Jon" To: "'Michael Thomas'" , "Peterson, Jon" Cc: sip@ietf.org Subject: RE: [Sip] TLS, IPSec and consensus (bug #232) Date: Wed, 30 Jan 2002 16:32:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Another round, bartender. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Wednesday, January 30, 2002 9:43 AM > To: Peterson, Jon > Cc: sip@ietf.org > Subject: [Sip] TLS, IPSec and consensus (bug #232) > > > > If you're going to gauge response to IPsec, you > need to do the same thing for TLS. I haven't seen > a whole lot of support for it either, and many > have raised objections to its obesity. Obesity in contrast with your IPSec proposal, which I believe we agreed is starved for confidentiality, key exchange, or PKI. If you fed these into your IPSec profile, I'm sure it would become pleasantly plump (and quite a bit more applicable to SIP and its security problems). TNSTAAFL. You get what you pay for with your 6K. > 3G isn't > planning to use it on UA's; that does not bode > well. The fact is, looking for support for either > is not likely to get you very far. History has > shown that ostrich behavior here is the preferred > solution, even though that's not acceptable. I agree that few people who read this list, unfortunately, are inclined to participate in this discussion. Most people want security and are content to let the security people figure it out. That leads us to the typical "silence = consensus" rhetoric that, equally unfortunately, disproportionately favors the incumbent. However, there has got to be a point where we have said our peace, and somebody needs to make a judgment about where we are. > > What I see right now is that we will not have an > interoperable standard for UA's. Well, I mean, we can have a standard - those are just paper documents. > This is reality > -- small footprint UA's will take the STRONGLY > RECOMMENDED and ignore it in the blink of an > eye. Implementations may ignore that, true. We welcome them to support IPSec in our paper document. > The SMIME recommendation is similarly a > non-starter. We have a e2e requirement, and S/MIME seems to satisfy it, if anyone wants to use it. > The only thing that has *any* > possibility of being implemented uniformly is > digest and the minimal IPsec I've been talking > about. Digest as it appears in bis06 buys us a little; not much. I think your IPSec profile probably buys us about as much Digest. In fact, if we fixed integrity for Digest (as several proposals have suggested), wouldn't Digest would actually provide a superset of functionality of your minimal IPSec profile? > Things that require hundreds of kb of code > are going to flop on the very devices that need > protection the most. > > > Mike > > Peterson, Jon writes: > > > > I would like to suggest, based on the list discussion that > has transpired to > > date, that the chairs consider whether or not we have > rough consensus in > > favor of the current normative text on TLS and IPSec in > bis06 22.3.1. > > > > The summary I sent out earlier today (along with Brian and > Mike's summaries) > > provides an account of the current state of the > discussion. I believe that > > the bis authors have been able to present a reasonable > response to Mike's > > strenuous objections. In any event, the issues are on the > table, and those > > who have debated these issues for months have essentially > said their peace. > > If there are any further arguments, or reflections on TLS vs. IPSec > > transport vs. IPSec tunnel, from other members of the SIP > community, let's > > hear them now, by all means. Most respondents have > indicated that they can > > live with the text in bis06 today. > > > > I would also note that to date the reception of the > proposed minimal IPSec > > profile (ESP transport mode HMAC-MD5-NULL) has been > lukewarm, I think. Some > > respondents have expressed a preference for tunnel mode > IPSec. The IESG also > > seems to feel that some encryption algorithm, as well as a > story about > > keying, should be a part of an IPSec profile for SIP. > While some encryption > > algorithms has been mentioned on the list (like DES, as > required by RFC > > 2406), I haven't heard one that people sound entirely > comfortable with. > > > > Ultimately, we all agree that we need to arrive at an > IPSec profile for SIP > > - I just don't believe that we need to solve this problem in bis. > > > > Jon Peterson > > NeuStar, Inc. > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 17:55:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04176 for ; Wed, 30 Jan 2002 17:55:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA28143 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 17:55:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27709; Wed, 30 Jan 2002 17:39:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27678 for ; Wed, 30 Jan 2002 17:39:49 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03954 for ; Wed, 30 Jan 2002 17:39:47 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0UMdBM27398; Wed, 30 Jan 2002 16:39:11 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 16:39:11 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187884@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Peterson, Jon'" , "'Rosen, Brian'" , sip@ietf.org Subject: RE: [Sip] TLS, IPSec and consensus (bug #232) Date: Wed, 30 Jan 2002 16:39:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A9DE.EE53FCC0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1A9DE.EE53FCC0 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Wednesday, January 30, 2002 1:05 PM > To: 'Rosen, Brian'; Peterson, Jon; sip@ietf.org > Subject: RE: [Sip] TLS, IPSec and consensus (bug #232) > > > Brian is right about the fact that both IPSec and TLS work > only for the > respective architectures to which they are applicable. I > agree that there is > a critical need for an IPSec profile - I think the only real > question is > whether or not it needs to be in bis in order for the > security story in bis > to be complete. I don't know of any litmus test for this. I > do know that I > got the impression that punting on confidentiality and keying > wouldn't be > acceptable. [SS] I agree. As you know, there has been some work going on adjunct to the SIP Security Design to enhance Digest to enable UA's authenticate Proxies (in particular, last hop Proxies), provide complete message integrity protection over last/first hop and prevent bid-down attacks. Without encryption & keying (those Digest can't address), the minimum IPSec profile won't be very useful. Sanjoy ------_=_NextPart_001_01C1A9DE.EE53FCC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] TLS, IPSec and consensus (bug #232)

> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz= ]
> Sent: Wednesday, January 30, 2002 1:05 = PM
> To: 'Rosen, Brian'; Peterson, Jon; = sip@ietf.org
> Subject: RE: [Sip] TLS, IPSec and consensus = (bug #232)
>
>
> Brian is right about the fact that both IPSec = and TLS work
> only for the
> respective architectures to which they are = applicable. I
> agree that there is
> a critical need for an IPSec profile - I think = the only real
> question is
> whether or not it needs to be in bis in order = for the
> security story in bis
> to be complete. I don't know of any litmus test = for this. I
> do know that I
> got the impression that punting on = confidentiality and keying
> wouldn't be
> acceptable.

[SS] I agree. As you know, there has been some work = going on adjunct to the SIP Security Design to enhance Digest to enable = UA's authenticate Proxies (in particular, last hop Proxies), provide = complete message integrity protection over last/first hop and prevent = bid-down attacks. Without encryption & keying (those Digest can't = address), the minimum IPSec profile won't be very useful.

Sanjoy



------_=_NextPart_001_01C1A9DE.EE53FCC0-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 18:05:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04429 for ; Wed, 30 Jan 2002 18:05:42 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29060 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 18:05:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27931; Wed, 30 Jan 2002 17:46:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27900 for ; Wed, 30 Jan 2002 17:46:56 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04054 for ; Wed, 30 Jan 2002 17:46:54 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0UMkQI23639; Wed, 30 Jan 2002 14:46:26 -0800 (PST) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACK42149 (AUTH rmahy); Wed, 30 Jan 2002 14:46:26 -0800 (PST) Message-Id: <200201302246.ACK42149@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com with HTTP/1.0; Wed, 30 Jan 2002 14:47:02 -0800 Date: Wed, 30 Jan 2002 14:47:02 -0800 From: Rohan Mahy Subject: RE: [Sip] solving early media, HERFP, and unifying manyfolks To: Alan Johnston Cc: "'Jonathan Rosenberg'" , "'Sanjoy Sen'" , sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Here are the requirements Jonathan listed in "unify": The general rule for offers and answers would then be the following: o A UA cannot send an offer when it has sent a previous offer to which it has not yet gotten an answer. o A UA cannot send an offer when it has received an offer to which it has not generated an answer. o A UA can only send an offer in a message that is sent reliably. o The answer to an offer has to occur in a message which is correlated to the message the offer came in. o If an offer does not take place in the first reliable message from UAC to UAS, it must be present in a reliable message from UAS to UAC. One side effect of allowing an offer/answer in any message matching the 4 requirements, is that you could (for example) put media on hold when sending a REFER. INV (offer1) -> <- 200 (answer1) ACK -> ... REFER (offer2) -> a=inactive: <- 202 (answer2) triggered INVITE -> etc... - You would definitely need to leave this decision to each new method (probably doesn't make sense in a SUBSCRIBE for example ;-). - Since PRACK is defined in bis, PRACK would need to define if it is OK. (I think it should be allowed in PRACK). thanks, -rohan ---- Original message ---- >Date: Wed, 30 Jan 2002 15:33:52 -0600 >From: Alan Johnston >Subject: RE: [Sip] solving early media, HERFP, and unifying manyfolks >To: "'Jonathan Rosenberg'" , "'Sanjoy Sen'" >Cc: sip@ietf.org > >Jonathan, > >I'd like to try to focus the discussion on the issue of the moment >(literally) relating to bis. > >While more discussion is needed before we can reach consensus on your >proposal, we need to agree right now if we want to make the one change >to bis to allow the possibility of this proposal. > >Right now, bis says that a 200 OK MUST have SDP, either an answer if the >INVITE had an offer, or an offer if the INVITE did not, in which case >the answer will be in the ACK. > >We would need to change bis to allow for the offer/answer to take place >outside of the INVITE/200/ACK exchange in an extension to SIP. > >I think it would be good to make this change, keeping the existing >offer/answer model but adding a statement that extensions may define new >ways of making offers or answers which could take the place of the bis >discussion. Perhaps this change is needed even for manyfolks COMET not >to contradict bis? > >Can we come to consensus on the list to agree to this change? > >Thanks, >Alan Johnston >WorldCom >sip:alan@siptest.wcom.com > >Jonathan Rosenberg wrote: > >> Sent: Wednesday, January 30, 2002 11:27 AM >> To: Sanjoy Sen >> Cc: sip@ietf.org >> Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks >> >> >> >> >> Sanjoy Sen wrote: >> > >> > Hi, >> > >> > Following are some of the comments on the unify draft: >> > >> > 1) The draft proposes a Reason header to carry the reason codes. >> > There's also a sipfrag approach of carrying the an entire SIP >> > request/response as a new Mime type. Should there be a >> single approach >> > and if they must be different, what're the pros and cons of their >> > usage? >> >> I was going for the simplest thing, since there seemed littl >> ebenefit to encapsulation as opposed to just including the >> headers and bodies within the provisional response, as needed. >> >> Is there a concrete reason why encapsulation is better? >> >> > >> > 2) Its not clear how the UA determines when to stop local >> ringing and >> > await early media. Pre-bis05 drafts mentioned using SDP >> within 183 to >> > indicate this to the UA. Does the UAC wait for a 1) new >> Offer, or 2) >> > an Answer, to stop any local ringing that might be taking place. I >> > guess the behavior would be same as for regular media, but it would >> > help if this is clarified. >> >> There is no difference between early media and media. Local >> alerting would presumably take place as a local >> implementation choice once a suitable provisional response >> (180, typically) has been received to indicate that the far >> end is, in fact, ringing. It would continue until the >> establishment of the session, early or otherwise. As a >> result, a 183 w/SDP finalizes the establishment of the >> session, and so that would stop any local ringback. >> >> I suppose that suspension of the session, with port zero, >> before the dialog is completed, would be a way to signal a >> UAC to revert back to local ringback, if that functionality >> was needed. >> >> >> > >> > 3) We support Rohan's proposal of using the new method >> UPDATE instead >> > of reusing the COMET, as the semantics are significantly different >> > than COMET. >> >> Seems to be a general consensus; I'd still like to hear from >> Bill on this topic in particular. >> >> > >> > 4) Another concern is, from 3GPP perspective, if this draft is the >> > replacement of manyfolks, then that calls for some major changes >> > within the 3GPP specs. I do not support inclusion of this >> in the bis, >> > but the bis should discuss these issues and refer to this >> draft as the >> > solution & this draft should be progressed towards the last >> call ASAP. >> >> I see little gain in having bis reference this document, that >> will introduce an unneeded dependency. >> >> I do agree that all of this, plus the recent route stuff, is >> going to be a lot of editing work for the folks maintaining >> 24.228. I certainly appreciate their work and patience in our >> struggle to get everything aligned and working for them. >> >> -Jonathan R. >> >> -- >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PH: (973) 952-5000 >> http://www.dynamicsoft.com >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current >> sip Use sipping@ietf.org for new developments on the >> application of sip >> > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 18:20:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04636 for ; Wed, 30 Jan 2002 18:20:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29437 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 18:20:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28955; Wed, 30 Jan 2002 18:04:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28929 for ; Wed, 30 Jan 2002 18:04:11 -0500 (EST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04409 for ; Wed, 30 Jan 2002 18:04:08 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 86A4A4CE07; Wed, 30 Jan 2002 18:04:11 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA02560; Wed, 30 Jan 2002 18:04:10 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id SAA25830; Wed, 30 Jan 2002 18:04:24 -0500 (EST) Date: Wed, 30 Jan 2002 18:04:24 -0500 (EST) Message-Id: <200201302304.SAA25830@fish.research.att.com> To: sip@ietf.org Cc: alan.johnston@wcom.com, jdrosen@dynamicsoft.com, sanjoy@nortelnetworks.com Subject: RE: [Sip] solving early media, HERFP, and unifying manyfolks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I'm in favor of adding text to bis to allow the offer/answer to take place outside of the INVITE/200/ACK, as defined by extensions. One problem identified in the previous manyfolks draft is that the answer SDP, which appears in the 183, needed to be repeated in the 200 in order to comply with bis. That leaves open the question of handling it if it is different. Text in manyfolks-03 stated that further SDP MUST NOT change the agreed media definitions, and Rohan pointed out problems with this statement in early media cases. Removing the requirement that it be repeated is a far better solution. This has implications for proxies (that want to know the final media SDP) needing to understand the extensions. I believe this can be avoided with a restriction on extensions that the 'most recent' SDP within a dialog is 'most valid', and that such a proxy needs to Record-Route to guarantee seeing the final offer&answer. Bill Marshall wtm@research.att.com -----original message----- Date: Wed, 30 Jan 2002 15:33:52 -0600 From: Alan Johnston Subject: RE: [Sip] solving early media, HERFP, and unifying manyfolks To: "'Jonathan Rosenberg'" , "'Sanjoy Sen'" Cc: sip@ietf.org Jonathan, I'd like to try to focus the discussion on the issue of the moment (literally) relating to bis. While more discussion is needed before we can reach consensus on your proposal, we need to agree right now if we want to make the one change to bis to allow the possibility of this proposal. Right now, bis says that a 200 OK MUST have SDP, either an answer if the INVITE had an offer, or an offer if the INVITE did not, in which case the answer will be in the ACK. We would need to change bis to allow for the offer/answer to take place outside of the INVITE/200/ACK exchange in an extension to SIP. I think it would be good to make this change, keeping the existing offer/answer model but adding a statement that extensions may define new ways of making offers or answers which could take the place of the bis discussion. Perhaps this change is needed even for manyfolks COMET not to contradict bis? Can we come to consensus on the list to agree to this change? Thanks, Alan Johnston WorldCom sip:alan@siptest.wcom.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 18:21:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04688 for ; Wed, 30 Jan 2002 18:21:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA29472 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 18:21:55 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28437; Wed, 30 Jan 2002 18:00:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28380 for ; Wed, 30 Jan 2002 18:00:03 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04300 for ; Wed, 30 Jan 2002 18:00:01 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g0UMwrb14591; Wed, 30 Jan 2002 17:58:53 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jan 2002 16:58:52 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAE7B@VA02> From: "Peterson, Jon" To: "'Jonathan Rosenberg'" Cc: "'Rohan Mahy'" , sip@ietf.org Subject: RE: [Sip] ambiguities with S/MIME Date: Wed, 30 Jan 2002 16:58:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Let me say off the bat that I agree, we need to clarify this. I think this goes back to the integrity issue. Some headers can be modified in transit, some cannot. If it is legitimate for a proxy server to modify a header in transit, we can say that a change in the value of such headers should not be considered an integrity breach (which we say in the text today). Today the only 'mutable' headers we list (and we're drawing only from headers that appear in bis06) are: Request-URI Via Record-Route Route Max-Forwards Proxy-Authorization Everything else is potentially an integrity breach. For encryption, you might want to treat these things differently - presumably, your intent in encrypting a 'message/sip' is to hide the value of some headers, so you presume that some of the headers will necessarily have different values. Today we don't really say anything about the applicability of this mechanism to particular headers Unclear why someone would want to obfuscate the CSeq (grin) - maybe it would be easier to list the headers in bis06 that it would make sense to obfuscate, which include, I think: To From Subject Reply-To Organization (of course, all Content-* headers) Then, we can say can say that for encrypted 'message/sip' bodies, any change to headers other than these, and those included on the integrity list above, may be an integrity breach. Does this make sense as a way of casting the problem? Or is there a way to get any better leverage on it? Anything that needs to be added to or subtracted from either list above? Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, January 30, 2002 12:05 PM > To: Peterson, Jon > Cc: 'Rohan Mahy'; sip@ietf.org > Subject: Re: [Sip] ambiguities with S/MIME > > > > > "Peterson, Jon" wrote: > > > > The question is really how you 'use' the inner headers. Most headers > > don't > > have any end-to-end semantic aside from the establishment > of a dialog > > ID. > > Well, there are things like CSeq for sequencing. OK, so here is an > example of what I mean. A sends B an INVITE, with a signed mime body. > They sent with CSeq 5. An attacker intercepts, modifies the outer CSeq > to 500, changing nothing else, and keeping the signature. This arrives > at the UAS. The UAS still uses the outer headers, so it updates the > remote CSeq to 500. Now, the UAS will reject any subsequent messages > from the UAC, since they will have a CSeq that is too low. > > This is similar to a registration attack which I think James pointed > out. I suppose the same argument I made there could apply here, which > is, that the middleman could just instead through away the packet with > the same result, and that is an insurmountable attack. > > However, the point is really that it is not obvious that there are no > security consequences with using some of the non-informational headers > from the outside. I don't think this is a hard problem to fix, we just > need to think it through and make sure we know whcih ones are > the right > ones to use, and if there is a general way to describe it. > > > > On the multiple signatures thing, I agree there aren't very > many obvious > > reasons for signing a message with multiple identities (any mental > > problems > > aside). Maybe if the originating user suspect that they > were known by > > different identities to different potential recipients of > the request > > (not > > sure why that would be, admittedly), they might want to > sign the message > > multiple times. Simplest answer is to limit to one > signature, I think. > > Agreed. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 18:45:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04882 for ; Wed, 30 Jan 2002 18:45:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA00398 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 18:45:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29247; Wed, 30 Jan 2002 18:12:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29216 for ; Wed, 30 Jan 2002 18:12:57 -0500 (EST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04560 for ; Wed, 30 Jan 2002 18:12:54 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 59D8E1E002 for ; Wed, 30 Jan 2002 18:12:57 -0500 (EST) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA02706; Wed, 30 Jan 2002 18:12:54 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id SAA51834; Wed, 30 Jan 2002 18:14:42 -0500 (EST) Date: Wed, 30 Jan 2002 18:14:42 -0500 (EST) Message-Id: <200201302314.SAA51834@fish.research.att.com> To: sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan wrote: > Sanjoy Sen wrote: > > > > 3) We support Rohan's proposal of using the new method UPDATE instead > > of reusing the COMET, as the semantics are significantly different > > than COMET. > > Seems to be a general consensus; I'd still like to hear from > Bill on this topic in particular. > I support the idea of manyfolks using a general UPDATE method, instead of a specific COMET method. Are there backward compatability concerns with such a change? Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 19:28:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05300 for ; Wed, 30 Jan 2002 19:28:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01799 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 19:28:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01159; Wed, 30 Jan 2002 19:04:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01128 for ; Wed, 30 Jan 2002 19:04:08 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05072 for ; Wed, 30 Jan 2002 19:04:05 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0V03a612642; Wed, 30 Jan 2002 16:03:36 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAU14115; Wed, 30 Jan 2002 16:03:05 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA22019; Wed, 30 Jan 2002 16:03:35 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.35287.613444.1112@thomasm-u1.cisco.com> Date: Wed, 30 Jan 2002 16:03:35 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] TLS is not a "transport" In-Reply-To: <70565611B164D511957A001083FCDD56CAAE79@VA02> References: <70565611B164D511957A001083FCDD56CAAE79@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > I'm not sure how a SIP application would know whether or not SIP is running > over IPSec in some architectures. Especially problematic under your proposal > are cases in which a SIP application sends a Via header in a request > indicating that the current transport is UDP/IPSec, but this message passes > through a security gateway, and by the time it reaches the next hop it has > in fact become over UDP/IP (and this seems to be one of several related > cases). I'm also not sure what we would get out of this (then again, nor am > I entirely sure we get out of having transport=tls rather than just > transport=tcp - but that's a whole different kettle of fish). I don't understand half of this, but it's hardly important. The current mechansim doesn't provide a means to specify SCTP over TLS. What now? 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 daemon@optimus.ietf.org Wed Jan 30 19:29:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05334 for ; Wed, 30 Jan 2002 19:29:55 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA01852 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 19:29:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01282; Wed, 30 Jan 2002 19:07:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01251 for ; Wed, 30 Jan 2002 19:07:53 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05089 for ; Wed, 30 Jan 2002 19:07:52 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0V07M626850; Wed, 30 Jan 2002 16:07:22 -0800 (PST) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACK43141 (AUTH rmahy); Wed, 30 Jan 2002 16:07:22 -0800 (PST) Message-Id: <200201310007.ACK43141@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com with HTTP/1.0; Wed, 30 Jan 2002 16:07:59 -0800 Date: Wed, 30 Jan 2002 16:07:59 -0800 From: Rohan Mahy Subject: RE: [Sip] ambiguities with S/MIME To: "Peterson, Jon" Cc: "'Jonathan Rosenberg'" , "'Rohan Mahy'" , sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit inline... ---- Original message ---- >Date: Wed, 30 Jan 2002 16:58:47 -0600 >From: "Peterson, Jon" >Subject: RE: [Sip] ambiguities with S/MIME >To: "'Jonathan Rosenberg'" >Cc: "'Rohan Mahy'" , sip@ietf.org > > >Let me say off the bat that I agree, we need to clarify this. I think this >goes back to the integrity issue. Some headers can be modified in transit, >some cannot. If it is legitimate for a proxy server to modify a header in >transit, we can say that a change in the value of such headers should not be >considered an integrity breach (which we say in the text today). Today the >only 'mutable' headers we list (and we're drawing only from headers that >appear in bis06) are: > >Request-URI >Via >Record-Route >Route >Max-Forwards >Proxy-Authorization > >Everything else is potentially an integrity breach. > >For encryption, you might want to treat these things differently - >presumably, your intent in encrypting a 'message/sip' is to hide the value >of some headers, so you presume that some of the headers will necessarily >have different values. Today we don't really say anything about the >applicability of this mechanism to particular headers Unclear why someone >would want to obfuscate the CSeq (grin) - maybe it would be easier to list >the headers in bis06 that it would make sense to obfuscate, which include, I >think: > >To >From >Subject >Reply-To >Organization >(of course, all Content-* headers) I can think of valid reasons for these to be private as well: Accept-* (especially Accept-Language) Authorization (username) *-Info Expires In-Reply-To Priority Require/Supported/Unsupported Retry-After User-Agent/Server Warning The following seem to be silly to encrypt, and maybe should be ignored: Call-ID Contact CSeq Date Min-Expires MIME-Version Proxy-* RAck RSeq Timestamp WWW-Authenticate thanks, -rohan >Then, we can say can say that for encrypted 'message/sip' bodies, any change >to headers other than these, and those included on the integrity list above, >may be an integrity breach. > >Does this make sense as a way of casting the problem? Or is there a way to >get any better leverage on it? Anything that needs to be added to or >subtracted from either list above? > >Jon Peterson >NeuStar, Inc. > >> -----Original Message----- >> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> Sent: Wednesday, January 30, 2002 12:05 PM >> To: Peterson, Jon >> Cc: 'Rohan Mahy'; sip@ietf.org >> Subject: Re: [Sip] ambiguities with S/MIME >> >> >> >> >> "Peterson, Jon" wrote: >> > >> > The question is really how you 'use' the inner headers. Most headers >> > don't >> > have any end-to-end semantic aside from the establishment >> of a dialog >> > ID. >> >> Well, there are things like CSeq for sequencing. OK, so here is an >> example of what I mean. A sends B an INVITE, with a signed mime body. >> They sent with CSeq 5. An attacker intercepts, modifies the outer CSeq >> to 500, changing nothing else, and keeping the signature. This arrives >> at the UAS. The UAS still uses the outer headers, so it updates the >> remote CSeq to 500. Now, the UAS will reject any subsequent messages >> from the UAC, since they will have a CSeq that is too low. >> >> This is similar to a registration attack which I think James pointed >> out. I suppose the same argument I made there could apply here, which >> is, that the middleman could just instead through away the packet with >> the same result, and that is an insurmountable attack. >> >> However, the point is really that it is not obvious that there are no >> security consequences with using some of the non- informational headers >> from the outside. I don't think this is a hard problem to fix, we just >> need to think it through and make sure we know whcih ones are >> the right >> ones to use, and if there is a general way to describe it. >> >> >> > On the multiple signatures thing, I agree there aren't very >> many obvious >> > reasons for signing a message with multiple identities (any mental >> > problems >> > aside). Maybe if the originating user suspect that they >> were known by >> > different identities to different potential recipients of >> the request >> > (not >> > sure why that would be, admittedly), they might want to >> sign the message >> > multiple times. Simplest answer is to limit to one >> signature, I think. >> >> Agreed. >> >> -Jonathan R. >> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >> Chief Scientist First Floor >> dynamicsoft East Hanover, NJ 07936 >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PH: (973) 952-5000 >> http://www.dynamicsoft.com >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Wed Jan 30 19:54:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05590 for ; Wed, 30 Jan 2002 19:54:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA03000 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 19:54:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01789; Wed, 30 Jan 2002 19:28:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA01757 for ; Wed, 30 Jan 2002 19:28:21 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05295 for ; Wed, 30 Jan 2002 19:28:19 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0V0RnG09562; Wed, 30 Jan 2002 16:27:49 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAU14818; Wed, 30 Jan 2002 16:27:18 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA22032; Wed, 30 Jan 2002 16:27:48 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.36740.90590.927886@thomasm-u1.cisco.com> Date: Wed, 30 Jan 2002 16:27:48 -0800 (PST) To: "Peterson, Jon" Cc: "'Jonathan Rosenberg'" , "'Michael Thomas'" , Juha Heinanen , "Rosen, Brian" , "'Dean Willis'" , sip@ietf.org Subject: RE: [Sip] TLS section In-Reply-To: <70565611B164D511957A001083FCDD56CAAE73@VA02> References: <70565611B164D511957A001083FCDD56CAAE73@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > While I'll come short of aggravated assault, I think the possibiliy of TLS > over IPSec is one of the reasons why we need to give some more thought to > interoperability of networks using these different security solutions. This > begs a lot of questions about how TLS would interact with transport mode as > opposed to tunnel mode IPSec. We'd probably want to avoid TLS over IPSec if > we can. Why do "we" care about this? "We" aren't designing networks here. All "we" need to talk about is what MUST/SHOULD/MAY be implemented. 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 daemon@optimus.ietf.org Wed Jan 30 20:07:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05672 for ; Wed, 30 Jan 2002 20:07:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA03804 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 20:07:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02793; Wed, 30 Jan 2002 19:52:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02765 for ; Wed, 30 Jan 2002 19:51:57 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05564 for ; Wed, 30 Jan 2002 19:51:56 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0V0pQG26806; Wed, 30 Jan 2002 16:51:26 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAU15406; Wed, 30 Jan 2002 16:50:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA22043; Wed, 30 Jan 2002 16:51:25 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15448.38157.712575.304854@thomasm-u1.cisco.com> Date: Wed, 30 Jan 2002 16:51:25 -0800 (PST) To: "Peterson, Jon" Cc: "'Michael Thomas'" , sip@ietf.org Subject: RE: [Sip] TLS, IPSec and consensus (bug #232) In-Reply-To: <70565611B164D511957A001083FCDD56CAAE7A@VA02> References: <70565611B164D511957A001083FCDD56CAAE7A@VA02> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Peterson, Jon writes: > > If you're going to gauge response to IPsec, you > > need to do the same thing for TLS. I haven't seen > > a whole lot of support for it either, and many > > have raised objections to its obesity. > > Obesity in contrast with your IPSec proposal, which I believe we agreed is > starved for confidentiality, key exchange, or PKI. If you fed these into > your IPSec profile, I'm sure it would become pleasantly plump (and quite a > bit more applicable to SIP and its security problems). Jon, Let's not be disingenuous here. The point is that you can decompose IPsec in ways you cannot decompose TLS. Nobody is prevented from fattening up their offering. However, if you require small UA's to be force fed a diet that they cannot digest, you are much more likely to get a dead UA instead of foie gras. > > What I see right now is that we will not have an > > interoperable standard for UA's. > > Well, I mean, we can have a standard - those are just paper documents. An unimplemented standard is a waste of paper. > > The SMIME recommendation is similarly a > > non-starter. > > We have a e2e requirement, and S/MIME seems to satisfy it, if anyone wants > to use it. Right now it's a SHOULD. As in strongly recommended. That says that there needs to be very good reasons why you don't do it. Right now, given the feedback on requirements, etc, I don't think that e2e crypto rises to even a SHOULD. Nobody implemented PGP, and nobody's been clamoring for a replacement. It seems to be a solution in search of a problem. > Digest as it appears in bis06 buys us a little; not much. I think your IPSec > profile probably buys us about as much Digest. In fact, if we fixed > integrity for Digest (as several proposals have suggested), wouldn't Digest > would actually provide a superset of functionality of your minimal IPSec > profile? It wouldn't have the ability to add encryption, key distibution, etc, in a standard way. Remember this is a *minimum*. Fixing all of that for Digest would be a *huge* job! 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 daemon@optimus.ietf.org Wed Jan 30 20:08:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05693 for ; Wed, 30 Jan 2002 20:08:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA03840 for sip-archive@odin.ietf.org; Wed, 30 Jan 2002 20:08:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02967; Wed, 30 Jan 2002 19:53:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02863 for ; Wed, 30 Jan 2002 19:53:49 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05578 for ; Wed, 30 Jan 2002 19:53:47 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0V0rIG28257; Wed, 30 Jan 2002 16:53:18 -0800 (PST) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACK43698 (AUTH rmahy); Wed, 30 Jan 2002 16:53:17 -0800 (PST) Message-Id: <200201310053.ACK43698@imop.cisco.com> Received: from 171.68.225.134 by imop.cisco.com with HTTP/1.0; Wed, 30 Jan 2002 16:53:55 -0800 Date: Wed, 30 Jan 2002 16:53:55 -0800 From: Rohan Mahy Subject: Re: [Sip] TLS is not a "transport" To: Michael Thomas Cc: Jonathan Rosenberg , Michael Thomas , sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I have to agree with Mike here that ;transport=TLS will become ambigous when we have TLS over SCTP. How about this ? tls+tcp or tls.tcp this is legal in the current BNF and allows for tls+sctp or tls.sctp at a later date. i don't want to get into the ipsec.* debate now however. thanks, -rohan ---- Original message ---- >Date: Wed, 30 Jan 2002 09:33:56 -0800 (PST) >From: Michael Thomas >Subject: Re: [Sip] TLS is not a "transport" >To: Jonathan Rosenberg >Cc: Michael Thomas , sip@ietf.org > >Jonathan Rosenberg writes: > > > > > > Michael Thomas wrote: > > > > > > The bis-06 draft improperly conflates TLS with a > > > transport protocol. This is incorret as it should > > > be obvious if you want to use TLS over SCTP. Any > > > conflation of this kind should be removed. HTTP > > > got this wrong too. Better would be to have some > > > sort of naming scheme which says: "SIP over > > > transport protected by security protocol". > > > > Are you arguing that instead of: > > > > sip:user@domain;transport=tls > > > > it should be: > > > > sip:user@domain;transport=sip-over-tcp-protected-by-tls? > > > > I think "tls" is better since its 3 bytes, compared to 29. > > > > I suppose what you really mean is that the text needs to indicate that > > TLS is not a transport, but we use the transport=tls parameter to > > indicate that the UAC needs to use TCP protected by TLS. > > > > Or are you arguing something else? > > I'm saying that your taxonomy is wrong. It should > be something of the form: > > transport=tls.tcp or transport= tls.sctp > > then you can also have things like: > > transport=ipsec.tcp or transport=foo.udp > > Even if you don't like the ipsec part, we already > need to consider tls over sctp. What's currently in > bis makes adding that pretty kludgey. > > 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 daemon@optimus.ietf.org Thu Jan 31 01:25:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11890 for ; Thu, 31 Jan 2002 01:25:58 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA25262 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 01:25:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14750; Thu, 31 Jan 2002 00:54:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14721 for ; Thu, 31 Jan 2002 00:54:45 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11532 for ; Thu, 31 Jan 2002 00:54:43 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0V5seX4005273 for ; Thu, 31 Jan 2002 06:54:40 +0100 (MET) Received: from lmf.ericsson.se (lmf04630pc.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0V5sdr6022325 for ; Thu, 31 Jan 2002 07:54:39 +0200 (EET) Message-ID: <3C58DC1E.68FA016F@lmf.ericsson.se> Date: Thu, 31 Jan 2002 07:54:38 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] MUST for digest Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I have a question on the "MUST" for UA support of digest authentication. What does this "MUST" really mean? Does it mean that a UA MUST be able to authenticate an incoming call, ie send 401? Does it mean a UA MUST be able to send a new INVITE if it receives 401/407? Does it mean a UA MUST be able to insert the credentials in the initial INVITE? Or, is the "MUST" there simply to "motivate" people to implement and start using authentication in their networks? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 31 01:29:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11941 for ; Thu, 31 Jan 2002 01:29:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA25445 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 01:29:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20007; Thu, 31 Jan 2002 01:08:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19924 for ; Thu, 31 Jan 2002 01:08:40 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11709 for ; Thu, 31 Jan 2002 01:08:38 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g0V68bX4008941; Thu, 31 Jan 2002 07:08:37 +0100 (MET) Received: from lmf.ericsson.se (lmf04630pc.lmf.ericsson.se [131.160.30.135]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g0V68br6023066; Thu, 31 Jan 2002 08:08:37 +0200 (EET) Message-ID: <3C58DF63.DA4D0E09@lmf.ericsson.se> Date: Thu, 31 Jan 2002 08:08:35 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: Michael Thomas , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] TLS is not a "transport" References: <200201310053.ACK43698@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I think we should decide the protocol level the transport parameter should specify. Otherwise one could argue that the IP version should also be there (tls.tcp.ip4, udp.ip6 etc etc). Personally I don't think the SIP application should care about what is under the transport protocol level, so I see no reason to include "ipsec" in the transport parameter (tcp.ipsec etc). For TLS, I agree with Rohan and Mike on tha fact that it should be possible to differentiate between TLS/TCP and TLS/SCTP. Just my thoughts... Regards, Christer Holmberg Ericsson Finland Rohan Mahy wrote: > > I have to agree with Mike here that ;transport=TLS will > become ambigous when we have TLS over SCTP. > > How about this ? > > tls+tcp or tls.tcp > > this is legal in the current BNF and allows for > > tls+sctp or tls.sctp > > at a later date. i don't want to get into the ipsec.* > debate now however. > > thanks, > -rohan > > ---- Original message ---- > >Date: Wed, 30 Jan 2002 09:33:56 -0800 (PST) > >From: Michael Thomas > >Subject: Re: [Sip] TLS is not a "transport" > >To: Jonathan Rosenberg > >Cc: Michael Thomas , sip@ietf.org > > > >Jonathan Rosenberg writes: > > > > > > > > > Michael Thomas wrote: > > > > > > > > The bis-06 draft improperly conflates TLS with a > > > > transport protocol. This is incorret as it should > > > > be obvious if you want to use TLS over SCTP. Any > > > > conflation of this kind should be removed. HTTP > > > > got this wrong too. Better would be to have some > > > > sort of naming scheme which says: "SIP over > > > > transport protected by security protocol". > > > > > > Are you arguing that instead of: > > > > > > sip:user@domain;transport=tls > > > > > > it should be: > > > > > > sip:user@domain;transport=sip-over-tcp-protected-by-tls? > > > > > > I think "tls" is better since its 3 bytes, compared to > 29. > > > > > > I suppose what you really mean is that the text needs to > indicate that > > > TLS is not a transport, but we use the transport=tls > parameter to > > > indicate that the UAC needs to use TCP protected by TLS. > > > > > > Or are you arguing something else? > > > > I'm saying that your taxonomy is wrong. It should > > be something of the form: > > > > transport=tls.tcp or transport= tls.sctp > > > > then you can also have things like: > > > > transport=ipsec.tcp or transport=foo.udp > > > > Even if you don't like the ipsec part, we already > > need to consider tls over sctp. What's currently in > > bis makes adding that pretty kludgey. > > > > 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 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 31 01:32:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12021 for ; Thu, 31 Jan 2002 01:32:10 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA25947 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 01:32:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22970; Thu, 31 Jan 2002 01:12:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22919 for ; Thu, 31 Jan 2002 01:12:09 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11746 for ; Thu, 31 Jan 2002 01:12:08 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0V6CJ6Y008860; Thu, 31 Jan 2002 01:12:19 -0500 (EST) Message-ID: <3C58E01A.19D6CD6F@dynamicsoft.com> Date: Thu, 31 Jan 2002 01:11:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: sip@ietf.org Subject: Re: [Sip] MUST for digest References: <3C58DC1E.68FA016F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > I have a question on the "MUST" for UA support of digest authentication. It means MUST implement; whether it is used or not is always a local choice. > > What does this "MUST" really mean? Does it mean that a UA MUST be able > to authenticate an incoming call, ie send 401? No, that would be a choice for the implementation. > Does it mean a UA MUST be > able to send a new INVITE if it receives 401/407? Yes; since it has implemented digest, it would follow the specification in terms of producing an updated INVITE with credentials (assuming it had them, of course). > Does it mean a UA MUST > be able to insert the credentials in the initial INVITE? That would be a choice for the implementation; the specification doesn't mandate that the initial INVITE contain credentials. > > Or, is the "MUST" there simply to "motivate" people to implement and > start using authentication in their networks? MUST implement is to provide minimal interoperability. It means that when a server wishes to authenticate a client, it can be sure to be able to do that with digest. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 31 01:40:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12115 for ; Thu, 31 Jan 2002 01:40:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26204 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 01:40:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25018; Thu, 31 Jan 2002 01:18:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA24977 for ; Thu, 31 Jan 2002 01:18:25 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11810 for ; Thu, 31 Jan 2002 01:18:23 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0V6I26Y008863; Thu, 31 Jan 2002 01:18:02 -0500 (EST) Message-ID: <3C58E172.2C00855C@dynamicsoft.com> Date: Thu, 31 Jan 2002 01:17:22 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org, alan.johnston@wcom.com, sanjoy@nortelnetworks.com Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <200201302304.SAA25830@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > I'm in favor of adding text to bis to allow the offer/answer to take > place outside of the INVITE/200/ACK, as defined by extensions. > > One problem identified in the previous manyfolks draft is that the > answer SDP, which appears in the 183, needed to be repeated in the > 200 in order to comply with bis. That would no longer be the case with the unify proposal. SDP could be present in the 200 OK, but that would mean its an offer, with an answer expected in ACK. > That leaves open the question > of handling it if it is different. Text in manyfolks-03 stated that > further SDP MUST NOT change the agreed media definitions, and Rohan > pointed out problems with this statement in early media cases. > Removing the requirement that it be repeated is a far better solution. Right; as I say above, you could put it there. It can be the same (O/A allows you to send an offer that is the same as previous), or can be different, but an answer would come in ACK in either case. > > This has implications for proxies (that want to know the final media > SDP) needing to understand the extensions. I believe this can > be avoided with a restriction on extensions that the 'most recent' > SDP within a dialog is 'most valid', and that such a proxy needs to > Record-Route to guarantee seeing the final offer&answer. Of course; thats not a change. If a proxy with rfc2543 wanted to see media information, it would need to record-route, since it could always change in a re-invite. There is no such thing as the "final" sdp, and there never was. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 31 01:48:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12222 for ; Thu, 31 Jan 2002 01:48:20 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26353 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 01:48:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25177; Thu, 31 Jan 2002 01:22:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25147 for ; Thu, 31 Jan 2002 01:22:01 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11855 for ; Thu, 31 Jan 2002 01:21:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0V6LY6Y008866; Thu, 31 Jan 2002 01:21:34 -0500 (EST) Message-ID: <3C58E245.3AB13CEC@dynamicsoft.com> Date: Thu, 31 Jan 2002 01:20:53 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall CC: sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <200201302314.SAA51834@fish.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit William Marshall wrote: > > Jonathan wrote: > > Sanjoy Sen wrote: > > > > > > 3) We support Rohan's proposal of using the new method UPDATE > instead > > > of reusing the COMET, as the semantics are significantly different > > > than COMET. > > > > Seems to be a general consensus; I'd still like to hear from > > Bill on this topic in particular. > > > > I support the idea of manyfolks using a general UPDATE method, > instead of a specific COMET method. Great! It seems like there is rough consensus on this point. > Are there backward compatability > concerns with such a change? I was hoping you could answer that question.... I would like to hear from folks who have implemented it. I suspect there are implementations but probably no deployments, but I could be wrong. I really don't care about backwards compatibility with implementations, but I don't want to break any existing deployments if we can avoid it. IETF is not even required to do that, since the IETF process warns implementors that drafts can change. Of course, the timetable of drafts in this group makes it more of a concern than normal. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 31 01:55:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12289 for ; Thu, 31 Jan 2002 01:55:51 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA26540 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 01:55:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25430; Thu, 31 Jan 2002 01:29:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA25401 for ; Thu, 31 Jan 2002 01:29:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11936 for ; Thu, 31 Jan 2002 01:29:12 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0V6TI6Y008870; Thu, 31 Jan 2002 01:29:18 -0500 (EST) Message-ID: <3C58E415.5A45C533@dynamicsoft.com> Date: Thu, 31 Jan 2002 01:28:37 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: Alan Johnston , "'Sanjoy Sen'" , sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <200201302246.ACK42149@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Hi, > > Here are the requirements Jonathan listed in "unify": > > The general rule for offers and answers would then be the > following: > > o A UA cannot send an offer when it has sent a previous offer > to which it has not yet gotten an answer. > > o A UA cannot send an offer when it has received an offer to > which it has not generated an answer. > > o A UA can only send an offer in a message that is sent > reliably. > > o The answer to an offer has to occur in a message which is > correlated to the message the offer came in. > > o If an offer does not take place in the first reliable > message from UAC to UAS, it must be present in a reliable > message from UAS to UAC. > > One side effect of allowing an offer/answer in any message > matching the 4 requirements, is that you could (for example) > put media on hold when sending a REFER. > > INV (offer1) -> > <- 200 (answer1) > ACK -> > ... > REFER (offer2) -> > a=inactive: > <- 202 (answer2) > triggered INVITE -> > etc... Well, I guess, although I must admit I hadn't thought about it. > > - You would definitely need to leave this decision to each > new method (probably doesn't make sense in a SUBSCRIBE for > example ;-). Right, agreed. Bis would need to say that. > > - Since PRACK is defined in bis, PRACK would need to define > if it is OK. (I think it should be allowed in PRACK). We need to discuss that further. Unify indicated that the preference was not to allow it in PRACK. I sent a note to the list already describing the reason. The reason is that you may need to reject an offer if it occurs in the middle of an outstanding offer (i.e., glare prevention). This means that if A sends a COMET to B with an offer, and B sends a PRACK to a previous 1xx with an offer to A, A will need to reject the PRACK for glare prevention. Since all requests are processed atomically (that has been unstated till now, formally stated in bis-06), that means that rejecting the PRACK means you effectively never got the PRACK, and thus retransmissions of the 1xx will continue. We don't thave the same problem for 2xx/ACK, since the glare prevention is at the broader level of the entire INVITE transaction. That is, you can't even send an INVITE w/o SDP (no offer) if you have received an INVITE with SDP. Now, maybe this point on PRACK is minor, but it is a concrete technical reason why NOT to. I welcome concrete technical reasons why we should, to compare them to find the right tradeoff. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 31 11:25:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02043 for ; Thu, 31 Jan 2002 11:25:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA01765 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 11:25:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27173; Thu, 31 Jan 2002 10:57:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27134 for ; Thu, 31 Jan 2002 10:57:37 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00665 for ; Thu, 31 Jan 2002 10:57:33 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA21009; Thu, 31 Jan 2002 10:53:34 -0500 (EST) Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g0VFrXJ1000729; Thu, 31 Jan 2002 10:53:33 -0500 (EST) Message-ID: <3C59687D.891C382@cs.columbia.edu> Date: Thu, 31 Jan 2002 10:53:33 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Rohan Mahy , Michael Thomas , Jonathan Rosenberg , sip@ietf.org Subject: Re: [Sip] TLS is not a "transport" References: <200201310053.ACK43698@imop.cisco.com> <3C58DF63.DA4D0E09@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree that commingling a shim layer like TLS and TCP is not exactly clean. In general, we're lacking a good term for these layers between transport and application (such as RTP and TLS); they are not really session or presentation layers, either. There are roughly three choices: (1) treat the label as just that; since the number of combinations is small, it doesn't matter if we call SCTP + TLS "bob" or "42". No application is magically going to go into its protocol toolbox and dynamically pull up the loadable library based on names in the parameter that it has never seen before. (2) Have something descriptive, like tcp.tls; (3) Label the shim layer separately, as in ;ts=tls (for transport security). (2) is the more readable version and 3 characters shorter than (3)... Christer Holmberg wrote: > > Hi, > > I think we should decide the protocol level the transport parameter > should specify. Otherwise one could argue that the IP version should > also be there (tls.tcp.ip4, udp.ip6 etc etc). > > Personally I don't think the SIP application should care about what is > under the transport protocol level, so I see no reason to include > "ipsec" in the transport parameter (tcp.ipsec etc). > > For TLS, I agree with Rohan and Mike on tha fact that it should be > possible to differentiate between TLS/TCP and TLS/SCTP. > > Just my thoughts... > > Regards, > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 31 12:44:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05056 for ; Thu, 31 Jan 2002 12:44:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA09361 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 12:44:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06425; Thu, 31 Jan 2002 12:05:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06399 for ; Thu, 31 Jan 2002 12:05:02 -0500 (EST) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03562 for ; Thu, 31 Jan 2002 12:04:57 -0500 (EST) Received: from DYN-VA-EXCH-001.dynamicsoft.com (dyn-va-exch-001 [63.114.208.70]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g0VH2XgZ025910; Thu, 31 Jan 2002 12:02:34 -0500 (EST) Received: by DYN-VA-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Jan 2002 12:04:27 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338EA1D@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Robert Sparks , "'sip@ietf.org'" Date: Thu, 31 Jan 2002 12:04:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: The right solution to sip routing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Vijay Gurbani pointed out an error in the example at the end of this message - the correction is below. > -----Original Message----- > From: Robert Sparks > Sent: Wednesday, January 30, 2002 12:42 AM > To: 'sip@ietf.org' > Subject: The right solution to sip routing > > > Folks - > > In the process of studying the potential problem points with > loose-routing as we've defined it so far, we've discovered > that a slight change in the way we look at the problem > has a high yeild. > > Basically, we want the Route mechanism to be right. We know > we've long had an issue with the strict-routing mechanism > in that it conflates the description of the next hop and > the intended target - this is the source of all the pain > with defining restrictions on loose routing such that > reasonable things happen when strict-routers are part > of the system. It is also the source of the convoluted > proxy record-route/route processing we've had to date, > including rewriting the RR URI so that it identifies the > intended target in both directions and the odd RR/Contact > munging that existed from bis-01 to -03. If we separate > identifying the target from specifying the next hop, all > those things go away. > > The change of approach is to look at what the sip routing > mechanism would be if we had a clean slate. Find what > the real "right thing" to do is, and then work in > as much backwards compatibility with existing strict > routing systems as is reasonable. > > So what is that right thing? > > What we want is for the Request-URI to represent the target > of the request and the Route header field to indicate resources > to visit on the path to that target. Instead of moving values > from the route header field into the Request-URI, proxies would use > the topmost route header field value to figure out where to send > the request (using the normal address/port/transport selection > mechanisms applied to that URI). Once the resource that is > indicated by that topmost route header value is reached, > then (and only then) that value is removed. > > More precisely, a proxy would execute the following steps in order: > > 1) Inspect the Request-URI, if it indicates a resource owned > by this proxy, run a location service and rewrite the R-URI > with the results. Otherwise, leave the R-URI alone. > > 2) Inspect the topmost Route header field value - if it > indicates this element, that route node as been reached > and it is removed. > > 3) Send the request to the resource in the topmost > Route header field value using the normal address/port/transport > resolution applied to that value (or using the Request-URI if > the Route header field has been exhausted). > > Variations on those steps that meet the requirements in the > looseroute proposal are valid, but its safe to say that the > above represents the typical scenario. > > If every element behaves this way, the Request-URI is never > overwritten with a Route header value, and Route header values > are removed when the element is reached. This last point is > pretty important. Only the node that the URI in that value > indicates can truly know that the node has been reached. > That URI can carry information critical to the processing > at that node. > > Proxy record-routing becomes much simpler. The reason it's > complex today is that the URI needs to both identify the > proxy AND the ultimate recipient. With the right approach, > it should just identify a service at that proxy. If there > was only one service, the proxy could record-route with > just its own address, which could be as simple as sip:1.2.3.4. > In most cases, there would be no need to rewrite this in > the response. > > Also, working with a clean slate, we would have UAs behave > differently than they currently do when they have a route set. > UAs should always place the target of the request in the > Request-URI. So, given a preloaded route, the RURI of the > initial request would indicate the resource the UA was trying > to reach, and the Route header field would contain elements > to be visited on the way. When a route set is established > by receiving a response with a Record-Route header field, > the UA puts the Contact from that response into the RURI of > future request, NOT into Route header field as the last element. > This way, the RURI indicates the real target of the request, > and the Route header field represents elements that need to be > visited to get there. > > So - if we could snap our fingers and have every deployed element > do the above "right thing", we'ld be in great shape - unfortunately > we have some deployed elements that will take time to change. > What is their impact and what can we reasonably do to work > with them? > > Encountering a strict-router while processing a request with > preloaded routes will destroy the target information carried > in the RURI. This is a hard and fast property of the way > strict-routing is defined, and we cannot work around it without > defining a new place to carry the "real" Request-URI. (Call it > a Request-URI: header field for the sake of argument.) This > is a terrible thing to do to the semantics of the protocol > just to preserve backwards compatibility with elements doing > something we find broken. The better approach is to bite the > bullet, define the "right thing" as above, and live with > the fact that encountering legacy strict-routers in the > particular case of processing an initial request with a > preloaded route will produce unpredictable results. > > However, we can assure that the most common usage of route > headers, mid-dialog routing based on URIs learned in > record-route/contact, will remain interoperable. > > Fortunately, we don't have real systems deployed that provide > preloaded routes. Anybody building such a thing needs to know > not to put strict-routing systems in it. People connecting > such systems need to know not to put strict-routers between > them. The case above is non-existant in deployed systems and > with care, we can keep its probability of ever occuring near > zero. > > We can make the story better for backwards compatibility with > existing endpoints. If we add the following restriction to > loose-routing proxy behavior, requests created by current > endpoints building Route headers fields based on Record-Route > header fields and Contacts will do the right thing: > > New Restriction 1: > * If a proxy receives a request with an RURI equal to a > value it placed in a Record-Route header, it MUST replace > that RURI with the first value in the Route header field. > > This will cause the flow of these subsequent requests > to effectively degenerate into the currently defined > strict-routing behavior if a "new" proxy is in a routed path > where upstream elements are "old" proxies or UAs. > > Now, we can make this even better by allowing elements that do > the "right thing" advertise that fact to other elements that > know what the right thing is. When such an element adds a value > to a Record-Route header field, have it include a ;lr parameter > in the value. When services create route sets to be used for > preloaded routes, have them include the ;lr parameter on each > value in that route set. > > With this knowledge, when an element (especially a "right thing" > aware endpoint) is preparing to send a request to the topmost > element in the Route set, it can notice that it is about to run > into a chain of one or more strict-routing elements and can format > the request so that any information it is carrying in the RURI > is preserved. The mechanics of this are simple. If the request > to send would otherwise have contained: > > METHOD targetURI > Route ,,, > > (For instance, this might have been formed by a UA that got > the targetURI from the Contact of a 200 to an INVITE, and built > the Route header field by flipping the values it recieved in a > Record-Route header field). > > the element can rebuild it to contain > > METHOD > Route ,,,, > > Or, in text form, the element puts the target URI into the > routeset after the first node indicating that it does > the "right thing", and follows it with another copy of that > nodes Route header value so that when that node gets the > request, it can use its normal processing (we'll see that in > action below). If there is no element in the Routee header field > indicating that it will do the right thing, the element adds the > target URI in as the last Route header field value. > > This gives the strict router the RequestURI it is expecting > (and is going to ignore) as well as the proper topmost Route > header field value to cause the request to move along the right > path. When the request gets to the element indicated by right1;lr, > it will look like > > METHOD rightthing1;lr > Route ,, > > According to New Restriction 1 above, the element at right1 > would replace the RURI with the topmost Route header field, > rendering > > METHOD targetURI > Route > > which the element at right1 can then apply its normal > processing to. > > Note that this degenerates to existing UA behaviors when all elements > are strict. When all elements understand this right thing, > it results > in the ideal behavior above, where Contact is in the URI, and the > record-route headers are in the route headers. When there is a mix of > proxies and UAs, the R-URI will have meaning for each element > understanding > how to do the right thing. > > I think this gives us the best story we're going to get. > > Here's a summary of what would change in bis: > * Add the New Restriction 1 above > * Define the ;lr parameter and when to include it > * Add the above description of what we expect most proxy > processing to be, emphasising the importance of having > the element indicated by the topmost route header field > value remove that value. > * Simplify the proxy record-routing procedures > * Add the above behavior for new UAs constructing requests from > Route-sets (putting the Contact element from the routeset > into the Request-URI instead of the last Route header field > value. > * Require all elements that know how to do this right thing to > perform the manipulation above to get around a string of > strict routing elements when they are encountered. > > The intent will be to gradually deprecate existing strict-routing. > In the same vein, the uses of maddr that have evolved to try to > get around some of the strict routing problems will be deprecated. > Proxies implementing this new approach have no need to (MUST NOT) > use maddr in any values they supply in Record-Route header fields. > > Here's an example flow that Jonathan worked out while we were > discussing this: > > The scenario is the sip trapezoid, U1 -> P1 -> P2 -> U2, with both > proxies record-routing. Here is the flow. > > U1 sends: > > INVITE sip:callee@domain.com SIP/2.0 > Contact: sip:caller@u1.example.com > > to P1. P1 is an outbound proxy. Following above rules, it isn't > domain.com, and there are no Route headers, so it looks it up > in DNS and > sends there. It also record-routes: > > INVITE sip:callee@domain.com SIP/2.0 > Contact: sip:caller@u1.example.com > Record-Route: > > P2 gets this. It owns domain.com. It runs a location service and > rewrites the URI. There are no route headers, so it sends to > the result > of the location lookup. It also record-routes with its addres: > > INVITE sip:caleee@u2.domain.com SIP/2.0 > Contact: sip:caller@u1.example.com > Record-Route: > Record-Route: > > The callee at u2 gets this. It responds with a 200 OK. That > 200 OK looks > like: > > SIP/2.0 200 OK > Contact: sip:callee@u2.domain.com > Record-Route: > Record-Route: > > This is forwarded by P2 to P1 to U1 as normal. Now, U1 will construct > the target, which is sip:callee@u2.domain.com, and a route > set, which is > sip:p1.example.com;lr, sip:p2.example.com;lr. Since all route hops are > new, it constructs the following for the BYE: > > BYE sip:callee@u2.domain.com SIP/2.0 > Route: > Route: Of course, this should have been BYE sip:callee@u2.domain.com SIP/2.0 Route: Route: > As any other element (including proxies) would do, it sends > this request > by looking up the top route in DNS, and sending there. This > goes to P1. > P1 follows same processing as before. The domain in the R-URI > is not its > own. So, it doesn't run location service, leaves r-uri alone. > There is a > route, which is its own, so its popped. THe next route is > there, and its > looked up in dns and the resulting address is used to forward the > request to P2: BYE sip:callee@u2.domain.com SIP/2.0 Route: > > Now, P2 looks at this. The R-URI is NOT ITS DOMAIN, since > u2.domain.com > is a specific host. So, it does not run location service. Like P1, it > notices the top route is its own, so its popped. There is no further > route, so the r-uri is looekd up in dns, and that is used to forward. > The following is then sent to u2: > > BYE sip:callee@u2.domain.com SIP/2.0 > > Voila! Everything works very nicely. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@optimus.ietf.org Thu Jan 31 13:38:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07289 for ; Thu, 31 Jan 2002 13:38:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA12683 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 13:38:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10908; Thu, 31 Jan 2002 13:03:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10839 for ; Thu, 31 Jan 2002 13:03:36 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06043; Thu, 31 Jan 2002 13:03:33 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0VI3D6Y009160; Thu, 31 Jan 2002 13:03:13 -0500 (EST) Message-ID: <3C5986B7.8DB8FF31@dynamicsoft.com> Date: Thu, 31 Jan 2002 13:02:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org, sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] updated offer/answer draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Folks, I have just submitted an update to the offer/answer model draft. Until it appears in the archives, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-mmusic-sdp-offer-answer-00.txt This draft includes all of the changes agreed to since IETF 52 and on the list since then. There are no open issues that I am aware of. Perhaps the most substantial change is the allowance of different payload type numbers in each direction, as per list discussion on mmusic. Other changes are noted in the changes section. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 14:36:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09407 for ; Thu, 31 Jan 2002 14:36:01 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA16784 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 14:36:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14302; Thu, 31 Jan 2002 14:07:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14272 for ; Thu, 31 Jan 2002 14:07:51 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08351 for ; Thu, 31 Jan 2002 14:07:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0VJ806Y009648; Thu, 31 Jan 2002 14:08:00 -0500 (EST) Message-ID: <3C5995E6.93F33634@dynamicsoft.com> Date: Thu, 31 Jan 2002 14:07:18 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sasha Ruditsky CC: "'sip@ietf.org'" Subject: Re: [Sip] The right solution to sip routing References: <0D5BBF5D638DD4119E3400508BD94945AE4A58@RADVPOST> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sasha Ruditsky wrote: > > Jonatan > > I just would like to get clarification on one thing: > You talk about "ability to finally discard the maddr parameter in the > URI". > Robert writes "the uses of maddr that have evolved to try to > get around some of the strict routing problems will be deprecated." > > More specifically: > Will the use of maddr to specify the multicast address be depricated or > not. That is a good question. Presuming no one is using it for multicast, in the process of going to draft it would be discarded as well. If there is indeed a use (although I can't think of it now), we could retain maddr for that aspect only. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 14:40:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09583 for ; Thu, 31 Jan 2002 14:40:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17479 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 14:40:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14676; Thu, 31 Jan 2002 14:16:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14648 for ; Thu, 31 Jan 2002 14:16:24 -0500 (EST) Received: from radvpost.us.radvision.com ([38.150.216.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08621 for ; Thu, 31 Jan 2002 14:16:20 -0500 (EST) Received: by RADVPOST with Internet Mail Service (5.5.2650.21) id ; Thu, 31 Jan 2002 14:14:28 -0500 Message-ID: <0D5BBF5D638DD4119E3400508BD94945AE4A5D@RADVPOST> From: Sasha Ruditsky To: "'Jonathan Rosenberg'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] The right solution to sip routing Date: Thu, 31 Jan 2002 14:14:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonatan So I believe the same (deprecation) should happen to the ttl parameter also. Sasha -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Thursday, January 31, 2002 2:07 PM To: Sasha Ruditsky Cc: 'sip@ietf.org' Subject: Re: [Sip] The right solution to sip routing Sasha Ruditsky wrote: > > Jonatan > > I just would like to get clarification on one thing: > You talk about "ability to finally discard the maddr parameter in the > URI". > Robert writes "the uses of maddr that have evolved to try to > get around some of the strict routing problems will be deprecated." > > More specifically: > Will the use of maddr to specify the multicast address be depricated or > not. That is a good question. Presuming no one is using it for multicast, in the process of going to draft it would be discarded as well. If there is indeed a use (although I can't think of it now), we could retain maddr for that aspect only. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 14:43:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09717 for ; Thu, 31 Jan 2002 14:43:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17621 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 14:43:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14215; Thu, 31 Jan 2002 14:07:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14150 for ; Thu, 31 Jan 2002 14:07:34 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08337 for ; Thu, 31 Jan 2002 14:07:30 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0VJ6I6Y009645; Thu, 31 Jan 2002 14:06:19 -0500 (EST) Message-ID: <3C599580.704EC1DE@dynamicsoft.com> Date: Thu, 31 Jan 2002 14:05:36 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" CC: Christer Holmberg , Rohan Mahy , Michael Thomas , sip@ietf.org Subject: Re: [Sip] TLS is not a "transport" References: <3C59687D.891C382@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Henning G. Schulzrinne" wrote: > > I agree that commingling a shim layer like TLS and TCP is not exactly > clean. In general, we're lacking a good term for these layers between > transport and application (such as RTP and TLS); they are not really > session or presentation layers, either. > > There are roughly three choices: > > (1) treat the label as just that; since the number of combinations is > small, it doesn't matter if we call SCTP + TLS "bob" or "42". No > application is magically going to go into its protocol toolbox and > dynamically pull up the loadable library based on names in the parameter > that it has never seen before. This has been my assumption. We clarified that the token "tls" means TLS over TCP. We can specify "tlsctp" as TLS/SCTP when its needed. Seems thats about the range of things we'll need to further worry about for some time. I'll also note that there are people using tls today, so changing the name of this label would present a bit of a compatibility issue. Let us not worry about non-problems. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 14:50:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09968 for ; Thu, 31 Jan 2002 14:50:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18677 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 14:50:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16949; Thu, 31 Jan 2002 14:36:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16884 for ; Thu, 31 Jan 2002 14:36:55 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09432 for ; Thu, 31 Jan 2002 14:36:51 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0VJYu625635; Thu, 31 Jan 2002 11:34:56 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAU31511; Thu, 31 Jan 2002 11:34:24 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA22465; Thu, 31 Jan 2002 11:34:54 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15449.40029.940911.468226@thomasm-u1.cisco.com> Date: Thu, 31 Jan 2002 11:34:53 -0800 (PST) To: "Sanjoy Sen" Cc: "'Peterson, Jon'" , "'Rosen, Brian'" , sip@ietf.org Subject: RE: [Sip] TLS, IPSec and consensus (bug #232) In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01187884@zrc2c012.us.nortel.com> References: <933FADF5E673D411B8A30002A5608A0E01187884@zrc2c012.us.nortel.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen writes: > [SS] I agree. As you know, there has been some work going on adjunct to the > SIP Security Design to enhance Digest to enable UA's authenticate Proxies > (in particular, last hop Proxies), provide complete message integrity > protection over last/first hop and prevent bid-down attacks. Without > encryption & keying (those Digest can't address), the minimum IPSec profile > won't be very useful. Again, this is a *minimum* requirement. IPsec has the ability to do these things in a completely standard and interoperability-proven way. Digest does not. Any UA is completely at liberty to go beyond minimum requirements. In fact, it is to be encouraged. 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 daemon@ns.ietf.org Thu Jan 31 15:06:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10557 for ; Thu, 31 Jan 2002 15:06:47 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20686 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 15:06:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19293; Thu, 31 Jan 2002 14:52:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19173 for ; Thu, 31 Jan 2002 14:52:09 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10024 for ; Thu, 31 Jan 2002 14:52:05 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g0VJpb609940; Thu, 31 Jan 2002 11:51:37 -0800 (PST) Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1]) by imop.cisco.com (Mirapoint) with SMTP id ACK52219 (AUTH rmahy); Thu, 31 Jan 2002 11:51:37 -0800 (PST) Message-Id: <200201311951.ACK52219@imop.cisco.com> Received: from 128.107.142.151 by imop.cisco.com with HTTP/1.1; Thu, 31 Jan 2002 11:52:23 -0800 Date: Thu, 31 Jan 2002 11:52:23 -0800 From: Rohan Mahy Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks To: Jonathan Rosenberg Cc: Rohan Mahy , Alan Johnston , "'Sanjoy Sen'" , sip@ietf.org X-Mailer: Mirapoint Webmail Direct 2.9.1.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I think I am missing something.... >Rohan Mahy wrote: >> The general rule for offers and answers would then be the >> following: >> >> 1) A UA cannot send an offer when it has sent a previous offer >> to which it has not yet gotten an answer. >> >> 2) A UA cannot send an offer when it has received an offer to >> which it has not generated an answer. >> >> 3) A UA can only send an offer in a message that is sent >> reliably. >> >> 4) The answer to an offer has to occur in a message which is >> correlated to the message the offer came in. >> >> 5) If an offer does not take place in the first reliable >> message from UAC to UAS, it must be present in a reliable >> message from UAS to UAC. >> - Since PRACK is defined in bis, PRACK would need to define >> if it is OK. (I think it should be allowed in PRACK). > >We need to discuss that further. Unify indicated that the preference was >not to allow it in PRACK. I sent a note to the list already describing >the reason. The reason is that you may need to reject an offer if it >occurs in the middle of an outstanding offer (i.e., glare prevention). >This means that if A sends a COMET to B with an offer, and B sends a >PRACK to a previous 1xx with an offer to A, A will need to reject the >PRACK for glare prevention. Would it help to add an additional restriction: Don't send a new offer if you are still waiting for acknowledgement of a message you sent in the same dialog. A would be forbidden to send an offer in a COMET (or a 200 for the original INVITE) until its provisionals where acknowledged. I think sending offers/answers in PRACK is even more useful in the 3pcc early media case. basically I prefer this: INVITE (no SDP) --> <-- 18x (offer1) PRACK (answer1) --> <-- 200 (PRACK) <-- 200 (INVITE) ACK --> to this: INVITE (no SDP) --> <-- 18x (offer1) PRACK --> <-- 200 (PRACK) COMET (answer1) --> <-- 200 (COMET) <-- 200 (INVITE) ACK --> (which is technically forbidden by rule 4 above) thanks, -rohan >Since all requests are processed atomically >(that has been unstated till now, formally stated in bis- 06), that means >that rejecting the PRACK means you effectively never got the PRACK, and >thus retransmissions of the 1xx will continue. > >We don't thave the same problem for 2xx/ACK, since the glare prevention >is at the broader level of the entire INVITE transaction. That is, you >can't even send an INVITE w/o SDP (no offer) if you have received an >INVITE with SDP. > >Now, maybe this point on PRACK is minor, but it is a concrete technical >reason why NOT to. I welcome concrete technical reasons why we should, >to compare them to find the right tradeoff. > >-Jonathan R. > >-- >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.jdrosen.net PH: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 15:57:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12177 for ; Thu, 31 Jan 2002 15:57:39 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA22713 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 15:57:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22294; Thu, 31 Jan 2002 15:42:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22263 for ; Thu, 31 Jan 2002 15:42:30 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11705 for ; Thu, 31 Jan 2002 15:42:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0VKgc6Y009732; Thu, 31 Jan 2002 15:42:38 -0500 (EST) Message-ID: <3C59AC14.79E78DE2@dynamicsoft.com> Date: Thu, 31 Jan 2002 15:41:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sasha Ruditsky CC: "'sip@ietf.org'" Subject: Re: [Sip] The right solution to sip routing References: <0D5BBF5D638DD4119E3400508BD94945AE4A5D@RADVPOST> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Sasha Ruditsky wrote: > > Jonatan > > So I believe the same (deprecation) should happen to the ttl parameter > also. > Sure, but that has little to do with the new routing proposals (just trying to keep us on track). Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 16:25:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13006 for ; Thu, 31 Jan 2002 16:25:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA24627 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 16:25:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23358; Thu, 31 Jan 2002 16:01:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23259 for ; Thu, 31 Jan 2002 16:01:33 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12291 for ; Thu, 31 Jan 2002 16:01:26 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0VKvj6Y009742; Thu, 31 Jan 2002 15:57:47 -0500 (EST) Message-ID: <3C59AF9F.FA0E8798@dynamicsoft.com> Date: Thu, 31 Jan 2002 15:57:03 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy CC: Alan Johnston , "'Sanjoy Sen'" , sip@ietf.org Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks References: <200201311951.ACK52219@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > >We need to discuss that further. Unify indicated that the > preference was > >not to allow it in PRACK. I sent a note to the list already > describing > >the reason. The reason is that you may need to reject an > offer if it > >occurs in the middle of an outstanding offer (i.e., glare > prevention). > >This means that if A sends a COMET to B with an offer, and B > sends a > >PRACK to a previous 1xx with an offer to A, A will need to > reject the > >PRACK for glare prevention. > > Would it help to add an additional restriction: Don't send a > new offer if you are still waiting for acknowledgement of a > message you sent in the same dialog. It would help, yes. Its broader than you need. I am trying to think if there would be an negative impacts from this restriction. None I can think of off hand, though. > > A would be forbidden to send an offer in a COMET (or a 200 > for the original INVITE) until its provisionals where > acknowledged. As a specific instance of your rule, yes. We could also make it simpler, which is that you can't send an offer in UPDATE (I think we have consensus to call it UPDATE) if you have a reliable provisional response outstanding. > > I think sending offers/answers in PRACK is even more useful > in the 3pcc early media case. > > basically I prefer this: > > INVITE (no SDP) --> > <-- 18x (offer1) > PRACK (answer1) --> > <-- 200 (PRACK) > <-- 200 (INVITE) > ACK --> > > to this: > > INVITE (no SDP) --> > <-- 18x (offer1) > PRACK --> > <-- 200 (PRACK) > COMET (answer1) --> > <-- 200 (COMET) > <-- 200 (INVITE) > ACK --> > > (which is technically forbidden by rule 4 above) Right, the benefit is the savings of a transaction. OK, I'll bite. I think the 3g guys would prefer this as well, since I suspect the case of 1-of-N codecs + manyfolks will be a common one. There, without sending SDP in PRACK, you'd need to to this: INVITE (SDP offer w/ many codecs + inactive + precon) ------> <----- 183 (SDP answer w/ one codec + inactive + precon)----- PRACK------> <----200 PRACK COMET (SDP offer w/ one codec + sendrecv + precon) -----------> <-------200 COMET (SDP answer w/ one codec + sendrecv + precon) <-----resource reservation--------> COMET (SDP offer w/ one codec + sendercv + conditions met)-------> <-------------200 COMET (SDP answer w/ one codec + sendrecv + conditions met) <---------180------------------------------------------------- PRACK---------------------> <-------------200 PRACK---- <-----------200 -----ACK> This is an extra pair of messages (an extra COMET) that is not currently in the flows in 24.228 which would need to be added. Whilst it *doesn't* increase call setup latency, it uses more bw on the air interface. Yeah, compression will help some, but I bet theyd prefer to avoid another transaction to an already overly complex setup flow. Of course, I think its even easier to avoid preconditions altogether, but let us not discuss that. So, let me ask for consensus on allowing the o/a exchanges in PRACK in addition to UPDATE, subject to some kind of constraint to avoid the problem I mention of glare on the PRACK. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 16:32:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13208 for ; Thu, 31 Jan 2002 16:32:44 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA25417 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 16:32:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23510; Thu, 31 Jan 2002 16:04:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23483 for ; Thu, 31 Jan 2002 16:04:09 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12371 for ; Thu, 31 Jan 2002 16:04:03 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g0VL3Sc11688; Thu, 31 Jan 2002 15:03:28 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 15:03:27 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0118788D@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jonathan Rosenberg'" Cc: sip@ietf.org Subject: RE: [Sip] solving early media, HERFP, and unifying manyfolks Date: Thu, 31 Jan 2002 15:03:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AA9A.B6E48680" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AA9A.B6E48680 Content-Type: text/plain; charset="iso-8859-1" Comments inline. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, January 30, 2002 11:27 AM > To: Sen, Sanjoy [NGC:B692:EXCH] > Cc: sip@ietf.org > Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks > > > > > Sanjoy Sen wrote: > > > > Hi, > > > > Following are some of the comments on the unify draft: > > > > 1) The draft proposes a Reason header to carry the reason > codes. There's > > also a sipfrag approach of carrying the an entire SIP > request/response > > as a new Mime type. Should there be a single approach and > if they must > > be different, what're the pros and cons of their usage? > > I was going for the simplest thing, since there seemed littl > ebenefit to > encapsulation as opposed to just including the headers and > bodies within > the provisional response, as needed. > > Is there a concrete reason why encapsulation is better? > Actually using a header such as Reason will probably be cheaper for parsing. > > > > There is no difference between early media and media. Local alerting > would presumably take place as a local implementation choice once a > suitable provisional response (180, typically) has been received to > indicate that the far end is, in fact, ringing. It would > continue until > the establishment of the session, early or otherwise. As a > result, a 183 > w/SDP finalizes the establishment of the session, and so that > would stop > any local ringback. > > I suppose that suspension of the session, with port zero, before the > dialog is completed, would be a way to signal a UAC to revert back to > local ringback, if that functionality was needed. Yes, but there would a problem with general PSTN interworking. When the MGC receives an ACM/Alerting message, it has no way to definitively infer whether the PSTN would generate early media (e.g., remote Ring-back or announcement). So, on receipt of ACM, the MGC may send an 180 (as you said) to the SIP phone which starts playing local ringing (by local implementation choice), but then any early media which might be coming through the gateway will be lost (the EM flow can start anytime after the ACM is issued). I was wondering what kind of rules do we need to specify to solve this issue and whether its at all solvable by rules alone. Sanjoy ------_=_NextPart_001_01C1AA9A.B6E48680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] solving early media, HERFP, and unifying = manyfolks

Comments inline.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, January 30, 2002 11:27 = AM
> To: Sen, Sanjoy [NGC:B692:EXCH]
> Cc: sip@ietf.org
> Subject: Re: [Sip] solving early media, HERFP, = and unifying manyfolks
>
>
>
>
> Sanjoy Sen wrote:
> >
> > Hi,
> >
> > Following are some of the comments on the = unify draft:
> >
> > 1) The draft proposes a Reason header to = carry the reason
> codes. There's
> > also a sipfrag approach of carrying the an = entire SIP
> request/response
> > as a new Mime type. Should there be a = single approach and
> if they must
> > be different, what're the pros and cons of = their usage?
>
> I was going for the simplest thing, since there = seemed littl
> ebenefit to
> encapsulation as opposed to just including the = headers and
> bodies within
> the provisional response, as needed.
>
> Is there a concrete reason why encapsulation is = better?
>
Actually using a header such as Reason will probably = be cheaper for parsing. 

> > <snip>
>
> There is no difference between early media and = media. Local alerting
> would presumably take place as a local = implementation choice once a
> suitable provisional response (180, typically) = has been received to
> indicate that the far end is, in fact, ringing. = It would
> continue until
> the establishment of the session, early or = otherwise. As a
> result, a 183
> w/SDP finalizes the establishment of the = session, and so that
> would stop
> any local ringback.
>
> I suppose that suspension of the session, with = port zero, before the
> dialog is completed, would be a way to signal a = UAC to revert back to
> local ringback, if that functionality was = needed.

Yes, but there would a problem with general PSTN = interworking. When the MGC receives an ACM/Alerting message, it has no = way to definitively infer whether the PSTN would generate early media = (e.g., remote Ring-back or announcement). So, on receipt of ACM, the = MGC may send an 180 (as you said) to the SIP phone which starts playing = local ringing (by local implementation choice), but then any early = media which might be coming through the gateway will be lost (the EM = flow can start anytime after the ACM is issued). I was wondering what = kind of rules do we need to specify to solve this issue and whether its = at all solvable by rules alone.

Sanjoy

------_=_NextPart_001_01C1AA9A.B6E48680-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 17:35:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14586 for ; Thu, 31 Jan 2002 17:35:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA29054 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 17:35:27 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27663; Thu, 31 Jan 2002 17:02:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27635 for ; Thu, 31 Jan 2002 17:02:43 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13968 for ; Thu, 31 Jan 2002 17:02:37 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g0VM29j02016 for ; Thu, 31 Jan 2002 17:02:09 -0500 (EST) Received: from lucent.com (mhapps3 [135.3.131.203]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id RAA27037 for ; Thu, 31 Jan 2002 17:02:08 -0500 (EST) Message-ID: <3C59BEB0.1CBEC3F5@lucent.com> Date: Thu, 31 Jan 2002 17:01:20 -0500 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP Mailing List Content-Type: multipart/mixed; boundary="------------1F79AFC07877494A3EC1B15D" Subject: [Sip] privacy draft and calling vs called Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------1F79AFC07877494A3EC1B15D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The privacy draft uses party = calling | called as the rpi-pty-type in the Remote-Party-ID header. The descriptions in 5.1 (assumed type if parameter is absent), 6.1 and 6.3 indentify "calling" with the sender of the request and "called" with the sender of a response. This seems obvious for an initial INVITE. But I want to confirm the intention for a reINVITE which does NOT come from the party that initiated the call. Should "calling" still be indentified with "requesting" even though the party is not the original calling party for the call? That is, should calling and called be reversed (as To and From are) from the original for the established call-leg or should they maintain their PSTN-like meaning with calling always referring to the party that initiated the call-leg? In either case, it would be helpful to be more explicit about usage for subsequent requests since "calling" and "called" are not SIP terms and might be confused with their PSTN usage. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------1F79AFC07877494A3EC1B15D Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard --------------1F79AFC07877494A3EC1B15D-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 19:11:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16073 for ; Thu, 31 Jan 2002 19:11:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA02882 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 19:11:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01342; Thu, 31 Jan 2002 18:43:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01311 for ; Thu, 31 Jan 2002 18:43:11 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15687 for ; Thu, 31 Jan 2002 18:43:06 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Thu, 31 Jan 2002 15:42:33 -0800 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 31 Jan 2002 15:42:32 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 15:42:33 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 15:42:32 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 31 Jan 2002 15:40:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Sip] TLS, IPSec and consensus (bug #232) Date: Thu, 31 Jan 2002 15:40:16 -0800 Message-ID: Thread-Topic: [Sip] TLS, IPSec and consensus (bug #232) Thread-Index: AcGqjlrDkU5k/20XQf+VqeDJlERZ6AAH70/A From: "Christian Huitema" To: "Michael Thomas" , "Sanjoy Sen" Cc: "Peterson, Jon" , "Rosen, Brian" , X-OriginalArrivalTime: 31 Jan 2002 23:40:16.0786 (UTC) FILETIME=[A2F29F20:01C1AAB0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA01312 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit A few points in the TLS/IPSEC debate: TLS, today, is much easier to deploy than IPSEC because of two factors, NAT traversal and one-way-authentication. We already heard of NAT traversal; TLS has a reasonable story; there is an IPSEC over UDP solution that is being developed, but it is sizably more complex than TLS. TLS enables one-way-authentication, i.e. a situation in which only the "server" is authenticated; IPSEC, in its current form, require that both server and clients have a certificate. Providing every client with a certificate turns out to be harder than expected. Note that in the case of either TLS and IPSEC, we have a dependency on the DNS. The "locating SIP servers" draft specifies the use of 1 or possibly two indirections: a NAPTR query to find the supported transports, then an SRV query to find the servers and port for the selected transport, and finally an A or AAAA query to find the address. DNS attacks such as cache pollution may be mounted at each of these steps. One way to protect against such attacks is to check that the names or credentials in the certificates used for TLS or IPSEC somehow match the domain part of the SIP URI. We should specify it. -- Christian Huitema _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 19:14:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16148 for ; Thu, 31 Jan 2002 19:14:06 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA02998 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 19:14:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01817; Thu, 31 Jan 2002 18:51:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA01789 for ; Thu, 31 Jan 2002 18:51:49 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15816 for ; Thu, 31 Jan 2002 18:51:44 -0500 (EST) Received: from there (bdsl.greycouncil.com [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g0VNpIH23151; Thu, 31 Jan 2002 17:51:18 -0600 Message-Id: <200201312351.g0VNpIH23151@bdsl.66.12.12.130.gte.net> Content-Type: text/plain; charset="iso-8859-15" From: Dean Willis To: sip@ietf.org Date: Thu, 31 Jan 2002 17:51:16 -0600 X-Mailer: KMail [version 1.3.2] Cc: dean.willis@softarmor.com MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] SIP bis RFC Work Plan and Call for Review Help Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Here's the current closing-up work plan for SIP bis. Beginning immediately, we need to subject bis-06 to "last call" type scrutiny. Get your comments in now, folks. Note that the loose-routing section is still being updated, as per Robert Sparks' recent email. Going forward: 4Feb -- incorporate comments, release bis07, begin formal WGLC 18Feb, -- end WGLC, incorporate comments 19Feb  -- release bis08, send to iesg for feedback 26Feb -- close feedback, incorporate all comments 27Feb -- send bis09 to IESG last call 7Mar  -- IESG meeting. Assuming IESG accepts, send draft to RFC editor, get RFC number, and send RFC# to 3GPP, as they need it before their plenary meetings end on 8Feb in Korea. I'd also like some "detail oriented" individuals to volunteer with "nits" review of bis07, making sure all the references and citations and MUSTS and SHOULDS and whatnot are spelled correctly. Clearly this does not mean me, as I cannot seem to spell "correctly". _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 19:34:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16537 for ; Thu, 31 Jan 2002 19:34:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA04009 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 19:35:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02787; Thu, 31 Jan 2002 19:07:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02756 for ; Thu, 31 Jan 2002 19:07:09 -0500 (EST) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16030 for ; Thu, 31 Jan 2002 19:07:06 -0500 (EST) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id AAA08023 for ; Fri, 1 Feb 2002 00:06:20 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id AAA22399 for ; Fri, 1 Feb 2002 00:07:07 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 17:07:05 -0700 Message-ID: <17052388D394D411803900508BDFFAF601B371A1@n0214idc1.oss.level3.com> To: sip@ietf.org Date: Thu, 31 Jan 2002 17:06:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] bis-06 comments/nits Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I didn't get to finish reviewing bis-06 yet, but wanted to post what I had so it hopefully makes it into bis-07 expected Monday. 1. Section 3 in the text version (PDF version OK) is missing a space in "SHALL NOT" (carried over from bis-05). 2. The text on figure 1 on page 11 is all messed up in the pdf version. Looks like a different language. 3. Line 389 indicates the example contains a minimum required set, but the newly mandatory Max-Forwards is not included. Max-Forwards also appears to be missing in other examples that otherwise appear to have the other minimum required headers, such as sections 11.1, 11.2, 21.4.1 (see note below), 21.4.2, and all requests in section 26. Note, it is debatable whether a Max-Forwards is required in a tunneled Invite as in section 21.4.1, this should get a bit of list discussion. My take is yes, incase some B2BUA or something takes it out and forwards it un-tunneled. I see no reason to special-case this. 4. Section 4, the example 200 OK has the Via list messed up. Looks like the first Via in the list (line 456) should be the last one (line 458). The last Via has the wrong branch compared to the Invite example. The first Via should probably have the biloxi domain in it, not the atlanta domain, and something different than pc33 to avoid reader confusion with the Via added by Alice's PC. 5. Line 1040, I can't recall in the list discussion if there was any specific reason to disallow the value from being more or less than the selected value of 70 beyond future proofing this for really big networks. The current wording locks UACs into always putting 70 in the header. I can see including the header is a MUST, but wonder if the stated value of 70 should be a SHOULD or RECOMMENDED to allow UAs some leeway. 6. Line 1151, is timeout the ONLY thing the TU will see? What happens when an ICMP host unreachable is returned? Does that not get to the TU? Related to this, should line 1184 "or network timeouts" be "or network failures"? 7. Line 1172 references non-existent section 22.10. 8. Line 1334, sooon should be soon. 9. Line 1351, delete last "the" in the line (grammar). 10. Line 1353, "amd" should be "and". 11. Line 1356 "complete" should be "completely". 12. Section 10.1 of the text version has a space before a comma in three places. PDF version is OK (lines 1493-1495). This was also a problem carried over from bis-05. John Hearty Level3 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From daemon@ns.ietf.org Thu Jan 31 23:04:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21062 for ; Thu, 31 Jan 2002 23:04:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA11838 for sip-archive@odin.ietf.org; Thu, 31 Jan 2002 23:04:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10767; Thu, 31 Jan 2002 22:39:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10742 for ; Thu, 31 Jan 2002 22:39:20 -0500 (EST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20635 for ; Thu, 31 Jan 2002 22:39:14 -0500 (EST) Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id TAA08765 for ; Thu, 31 Jan 2002 19:29:41 -0800 (PST) Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 19:40:14 -0800 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F409DF61A3@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: sip@ietf.org Date: Thu, 31 Jan 2002 19:39:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1AAD2.1FF21F20" Subject: [Sip] The TLS and IPSEC debate Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1AAD2.1FF21F20 Content-Type: text/plain; charset="iso-8859-1" As the original author of the DIGEST specification I thought I should explain what it exists for since it appears that there are some odd ideas on this list concerning its use. The objective of Digest was simply to define an interoperable mechanism that had no patent encumberances that allowed client authentication that did not cause passwords to go over the wire en-clair. Digest was not designed to provide many of the features you would want in a full featured authentication protocol such as a strong binding of the authentication data to the message. These features were avoided on purpose because the primary objective of DIGEST was to kill BASIC which had been released a week earlier. I seriously doubt that anyone could seriously asses the comparative complexity of TLS and IPSEC in favor of IPSEC these days. IPSEC has grown at least as large as TLS. A major reason for the explosion in IPSEC complexity is that the original design punted on some hard design choices such as key distribution. By the time the need for a key agreement mechanism was understood the designs had grown to baroque proportions due to the need to support multiple 'interim solutions' along the way. IPSEC and TLS both share a broadly similar approach to packaging. IPSEC is naturally packet oriented, TLS operates at the TCP level and is slightly cleaner to implement. The only practical differences are that IPSEC provides too many choices while TLS provides more choices than it needs to. I would strongly disrecommend any approach that attempted to 'profile' IPSEC. Either you support IPSEC or you do not. Attempting to define a subset of IPSEC loses all the advantages of using an off the shelf specification. It is not possible to use existing code. I also take exception to the implication that the vast majority of the IPSEC specification is somehow unnecessary and redundant, that RFC 2401 was sufficient on its own and the rest of the spec was developed for reasons other than real world customers needed the features in the real world. The main source of complexity in implementing TLS is that it is based on PKI and requires a PKI implementation. That need not be implemented at the device end however, a PKI interface protocol such as the W3C XKMS protocol can be used instead. From an architectural point of view TLS would appear to be better suited to the design requirements. IPSEC is designed to provide ubiquitous security, it is also designed to permit embedding at a very deep level in the network, one which would normally be shielded from the application in a conventional 'protocol stack' model. TLS is designed to interact with the application level. S/MIME would appear to be best suited of all since it is designed to support end to end security in a store and forward environment. I do not see how SIP could achieve any useful goals if the trust model was limited to manual exchange of (presumably symmetric) keys. I can certainly understand that giving the end user an incomplete solution saves development time. One cautionary tale of symmetric keys. Besides the published cryptographic failures of the 802.11b WEP protocol there is a much greater failure in that the 'Wired Equivalent Privacy' scheme failed to understand that in a wireless environment unauthorized network access was at least as serious an issue as confidentiality. So even before the crypto was discovered to be broken people did not deploy WEP because everyone on the network used the same shared secret for authentication and encryption. The root cause of the problem was that at the start of the protocol someone asserted that the protocol should be simple and this was accepted because simple is often mistaken for secure. Cryptographic protocols are not like a 'pick and mix' section in a candy store. IPSEC was issued as a set of RFCs for a purpose. RFC 2401 through 2411 are all IPSEC related. It is pure sophistry to pull out the message formats alone, as if ISAKMP and IKE were somehow optional extras added on as an afterthought. I have not had the time to perform a full security analysis of bis-6, however the 'kitchen sink' approach (support all the IETF crypto protocols) appears to be a pragmatic and reasonable response in this instance. The market will soon decide if there are superfluous mechanisms defined. In practice it is as Rohan suggests only really necessary to define interoperability MUST support at the server to server level, people will use servers that support their clients and choose clients that their servers support, need will drive sensible choices. I suspect that developers of lightweight clients would find XKMS more relevant to their constraints than the debate on TLS vs IPSEC. Supporting full blown PKI on constrained devices was a primary consideration in the design of XKMS. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 ------_=_NextPart_000_01C1AAD2.1FF21F20 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C1AAD2.1FF21F20-- _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
3 minutes seems a reasonable compromise. That will allow all but one of the ringtime
applications I am aware of work. I will begrudgingly accept it.
 
What this means is that any application that has a ringtime component can only
count on the overall system providing a maximum of 3 minutes of ringtime (since
some proxy in the path may have chosen to set Timer C to its 3 minute minimum).
 
It also means that until we do some other kind of work, we preclude access to
american airlines telephone service from the SIP world. (I _have_ stayed in the queue
on their system for significantly longer than 5 minutes from multiple residential, wireless,
and PBX phones, so something besides the timers discussed below is in play).
So, since the consensus is that really long timer C's are not the way to address this
problem, what's the alternative? Pretending the problem doesn't exist is unacceptable.
 
RjS
 
-----Original Message-----
From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com]
Sent: Tuesday, January 08, 2002 9:38 AM
To: taylor@nortelnetworks.com; wtm@research.att.com; sip@ietf.org
Subject: RE: [Sip] Default value for Timer C (was #282)

When I worked on the DMS several years ago, the timer was configurable, the company set it for 2 minutes.  I'm hearing a general concensus the timer should be in the 1-5 minute range.  Perhaps 3 minutes would be agreeable to most.  Haven't heard anyone new pipe up for very long times...
 
John Hearty
Level3
 
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, January 08, 2002 8:10 AM
To: 'William Marshall'; sip@ietf.org
Subject: RE: [Sip] Default value for Timer C (was #282)

A long time since I looked at that code, but I seem to recall a timeout after three minutes of ringing on the DMS.

-----Original Message-----
From: William Marshall [mailto:wtm@research.att.com]
Sent: Monday, January 07, 2002 10:12 PM
To: sip@ietf.org
Subject: Re: [Sip] Default value for Timer C (was #282)


In the circuit switch world, the equivalent of "Timer C" exists.
On a 5ESS, ringback turns to fast busy after 3 minutes.  On a 4ESS,
it happens after 90 seconds.  (Both figures were as of a few years
ago, but I doubt they have changed).  Perhaps someone from Nortel
could speak of the DMS switches.  Also as of a few years ago,
business customers paid for ring time, so if still true, it is not
clear why AA is "cheating".

So a timeout value of a couple of minutes (like 4) would work
just fine for calls into the PSTN, and would only get hit for
a high-and-dry type of defect.

Bill Marshall
wtm@research.att.com

-----original message-----
From: John.Hearty@Level3.com
Subject: RE: [Sip] Default value for Timer C (was #282)
Date: Mon, 7 Jan 2002 15:56:14 -0700

 I agree with Bob.  AA is apparently cheating here, doing all their IVR
functions without returning answer.  I vote for the alternative, choosing a
value on the order of minutes (not more than maybey three or four).

John Hearty
Level3

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, January 07, 2002 3:33 PM
To: Bob Penfield
Cc: Henry Sinnreich; 'Robert Sparks'; sip@ietf.org
Subject: Re: [Sip] Default value for Timer C (was #282)


This thread has stalled, and I think it requires some further input
before we can resolve it.

The issue was this: what minimum timer do we mandate for a proxy to hang
onto invite transaction state after receiving 1xx? The issue is that
some PSTN systems (american airlines in particular), appear to use early
media while a user is on hold waiting, or using the DTMF based IVR
system. The result is that a call from a PC to a PSTN number could, in
theory go legitimately unanswered for hours, perhaps. This would require
that Timer C in proxies be on the order of hours, which is quite large.

An alternative is to not consider this case, and choose a smaller value,
on the order of minutes.

Both can result in DoS attacks, although in this case, the proxy
shouldn't be storing transaction state for unauthenticated requests.

Determining whether or not to go with a large value depends a lot on how
common such systems are in the PSTN, and what the expectation is for
them to be properly supported.

Further inputs?

-Jonathan R.

Bob Penfield wrote:

>>>I have not _ever_ been able to successfully
>>>use my SIP equipment to have a successful dialog with AA.
>>>
>
> The same problem occurs using old-world TDM equipment. If I use my
> calling
> card account to call AA, it hangs up after about a minute because the
> calling card platform has a 60 second answer timer. AA is trying to save
> money by having their ACD not return an answer and thus they don't have
> to
> pay for the 800 call.
>
> BTW, all billing is based on answer (2xx for SIP) being returned by the
> called party. Some systems (usually in hotels) do use a timer when
> answer
> cannot be determined reliably (or they don't care).
>
> I'm curious as to whether this was isolated to a proxy or is it possible
> the
> TDM side of the gateway is dropping the call? If gateways have answer
> timers
> on this order of magnitude, having a really long timer in the proxy
> won't
> help.
>
> In any event, do we really need to support these cheaters in SIP and
> open
> ourselves to DOS attacks?
>
>
>>I have exactly the same experience.
>>As for:
>>
>>
>>>Now, if all the SIP parties involved allowed me to 1) control my
>>>own Expires header, and 2) actually honored the thing,
>>>
>>I don't know how to tweak to and I don't ever want to know.
>>
>>Is there a better approach to fix the timer value or am I missing
>>something?
>>
>>Thanks, Henry
>>
>>
>>>-----Original Message-----
>>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of
>>>
>>Robert
>>
>>>Sparks
>>>Sent: Thursday, December 27, 2001 9:57 AM
>>>To: 'Bob Penfield'; Jonathan Rosenberg; Robert Sparks
>>>Cc: sip@ietf.org
>>>Subject: [Sip] Default value for Timer C (was #282)
>>>
>>>I'm talking about a _real problem_ that I have
>>>_right now_ with the UAs on my desk and the gateways
>>>I have access to. I have not _ever_ been able to successfully
>>>use my SIP equipment to have a successful dialog with AA.
>>>Try it - call +18004337300 - my environment drops the unanswered
>>>call about 58 seconds into the first menu (yes, the first menu
>>>is over a minute long).
>>>
>>>Now, if all the SIP parties involved allowed me to 1) control my
>>>own Expires header, and 2) actually honored the thing, I could
>>>work around it. But what about my tweak-phobic aquaintances
>>>and relatives?
>>>
>>>In this case, the endpoints are dropping the call, but if I had
>>>otherwise behaving endpoints, and a proxy in the middle with a
>>>_default_ Timer C value that is too small, I am left with
>>>at least one well-known service that just doesn't work.
>>>
>>>Now, we could get into a discussion about whether or not a service
>>>_should_ run a whole bunch of time in an early media state, but
>>>that's rather moot - we've worked really hard to make the system
>>>allow it, and it will be used. We're here on purpose, not by
>>>misfortune of oversight.
>>>
>>>As for your last paragraph - who says early media has to be free?
>>>
>>>RjS
>>>
>>>
>>>
>>>>From: Bob Penfield [mailto:bpenfield@acmepacket.com]
>>>>
>>>>>>If this is acceptable, it still leaves us with the question
>>>>>>of what value we should recommend. I propose something
>>>>>>long - order of .5 to 1 hour (remember that calls stay in a
>>>>>>provisional state with early media when you are in the queue
>>>>>>to talk to an AA representative).
>>>>>>
>>>>>
>>>>>Egads, thats a long time! Your point on early media is well
>>>>>
> taken,
>
>>>>>though. Arguably, if this case happens, 1 hour is not even
>>>>>
>>>>enough, since
>>>>
>>>>>I have certainly been on hold for durations longer than
>>>>>
>>>>that. Probably 4
>>>>
>>>>>hours is more reasonable. Once you've set the timer this
>>>>>
>>>>high, it may as
>>>>
>>>>>well be any finite number as far as the proxy is concerned. The
>>>>>
>>only
>>
>>>>>value in having a number at all (as opposed to infinity) is
>>>>>
>>>>very long
>>>>
>>>>>term garbage collection. You will get NO DoS attack prevention
>>>>>
>>from
>>
>>>>>numbers of this magnitude. You really need to be careful,
>>>>>
>>>>as a proxy, to
>>>>
>>>>>not create transaction state unless the request is
>>>>>
>>>>authenticated somehow.
>>>>
>>>>I don't think this really applies. I believe that most ACD
>>>>systems that put
>>>>you on hold actually do answer the call. Especially ones that
>>>>have DTMF
>>>>menus since some carriers block the caller to callee
>>>>connection until it is
>>>>answered. Many TDM switches that I have experience with will
>>>>tear down an
>>>>unanswered connection after 1 or 2 minutes. I think a 2 or 3
>>>>minute timer
>>>>would be adequate.
>>>>
>>>>But, this is not the TDM world. So, if we want to provide for
>>>>unanswered
>>>>calls being queued for long periods of time, maybe we could
>>>>require the UAS
>>>>to send periodic provisional responses and the proxy could
>>>>reset Timer C.
>>>>But that may be getting to complicated.
>>>>
>>>>Service providers who charge for these calls don't want their
>>>>resources used
>>>>for free for such a long period of time.
>>>>
>>>>cheers,
>>>>(-:bob
>>>>
>>>>
>>>>_______________________________________________
>>>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>>>This list is for NEW development of the core SIP Protocol
>>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>>Use sipping@ietf.org for new developments on the application of
>>>>
> sip
>
>>>_______________________________________________
>>>Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
>>>This list is for NEW development of the core SIP Protocol
>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>Use sipping@ietf.org for new developments on the application of sip
>>>
>>
>


--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


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

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

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