From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 00:27:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11777 for ; Wed, 1 Mar 2000 00:27:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 44CB452D4; Wed, 1 Mar 2000 00:22:08 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9436252D5; Wed, 1 Mar 2000 00:22:07 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C16D952D4 for ; Wed, 1 Mar 2000 00:21:10 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 00:19:11 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 1 00:16:42 EST 2000 Received: from dynamicsoft.com (1Cust69.tnt2.freehold.nj.da.uu.net [63.17.114.69]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA11273; Wed, 1 Mar 2000 00:18:56 -0500 (EST) Message-ID: <38BCA96C.D85A8868@dynamicsoft.com> Date: Wed, 01 Mar 2000 00:23:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Cc: Dean Willis , Mart Nurmet , sip@lists.research.bell-labs.com Subject: Re: Information request! (Billing Package?) References: <4FBEA8857476D311A03300204840E1CF32E9FC@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > > Interesting, I assumed everything EXCEPT a gateway throws CDRs. > Assuming a decomposed gateway, the GW feeds statistics to a Call Agent > (which would be a SIP UA among other things) that throws CDRs. > > The billing system collates all the CDRs. > > The spec required is, of course, the format of the CDR and the way they > are transported. You could claim that a "transaction log" is a form of > CDR I suppose. My impression has been that the formats of these logs and data generated by gateways, servers, and so on, are generally vendor/device specific. Several companies make a living by allowing collection tools to read this data, based on templates provided to the systems, and generate standard CDRs. This has obviated the need for standard formats for these intermediary data records. > > I'd certainly agree that SIP itself doesn't have any "billing package". > A UA and a server might, but that is independent of the protocol. Billing > might very well impact some things in SIP. Actually, I think its the other way around. SIP impacts billing. Remember, one bills for services, not for protocols. "Billing for SIP" is itself actually meaningless. What you are billing for are gateway services, transport services, features, etc.. So, SIP impacts billing in the sense that it enables new services (such as those which combine web, email, etc. with voice), for which new models of what is billed for need to be thought out. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 01:03:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12210 for ; Wed, 1 Mar 2000 01:03:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CD53052C4; Wed, 1 Mar 2000 01:01:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3B50A52D6; Wed, 1 Mar 2000 01:01:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E465B52C4 for ; Wed, 1 Mar 2000 01:01:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 00:59:56 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 1 00:57:27 EST 2000 Received: from dynamicsoft.com (1Cust69.tnt2.freehold.nj.da.uu.net [63.17.114.69]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11315; Wed, 1 Mar 2000 01:00:00 -0500 (EST) Message-ID: <38BCB30B.B40347AD@dynamicsoft.com> Date: Wed, 01 Mar 2000 01:04:59 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Walker Cc: Henning Schulzrinne , Wing Man Kwok , sip@lists.research.bell-labs.com Subject: Re: SIP support of caller ID References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Bill Marshall has pointed out that the DCS mechanism addresses this. It also aims at enabling things like call trace and calling name/number delivery restriction. If you don't need all that, you can have authenticated caller ID in the base spec. You'll notice that the Authorization header allows for a signed-by attribute to indicate who signed the request. So, if I make a call, my local outbound proxy can authenticate me (say, using digest), and then do a real public key signature if the name in the From field is really me. The signed by attribute then indicates that the server signed the request. -Jonathan R. Dave Walker wrote: > > It sounds appealing. But what can we do about a user who feels like > lying? For example, I'll always answer a call from "Bill Gates" (or > will I??). If the user is known to a proxy in the signalling path, it's > possible for that proxy to insert or validate the display name and > then, more importantly, to signal that it has done so. This could, > for example, use a new addr-param (;screenedby=servername) in the From, > or a new header (Screened-Display: displayname servername). Of course, > this assumes that servers are more trustworthy than users. If someone's > server sends me too many fraudulent displaynames, maybe I'll just stop > accepting calls from it. > > Dave. > > > -----Original Message----- > > From: owner-sip@lists.research.bell-labs.com > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Henning > > Schulzrinne > > Sent: Tuesday, February 29, 2000 12:31 PM > > To: Wing Man Kwok > > Cc: 'sip@lists.research.bell-labs.com' > > Subject: Re: SIP support of caller ID > > > > > > Wing Man Kwok wrote: > > > > > > All, > > > > > > I read from the SIP FAQ that SIP supports caller ID. But I > > cannot find any > > > description of this in rfc2543. How does SIP support caller ID? > > > > Depends on the details, but basically, simply stick the caller name in > > the display name field, and the number in the user name. Done. > > > > > > > > Thanks in advance > > > > > > Wing Man Kwok > > > Telogy Networks > > > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 01:08:28 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12526 for ; Wed, 1 Mar 2000 01:08:27 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3798E52DB; Wed, 1 Mar 2000 01:05:40 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 17A7452DA; Wed, 1 Mar 2000 01:05:38 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2B12752DB for ; Wed, 1 Mar 2000 01:05:10 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 01:04:01 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 1 01:01:32 EST 2000 Received: from dynamicsoft.com (1Cust69.tnt2.freehold.nj.da.uu.net [63.17.114.69]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11320; Wed, 1 Mar 2000 01:04:03 -0500 (EST) Message-ID: <38BCB3FE.1E0803C1@dynamicsoft.com> Date: Wed, 01 Mar 2000 01:09:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Benny Prijono Cc: "sip@lists.research.bell-labs.com" Subject: Re: Loop detection in Invite request in stateless proxy References: <38BBF521.C450DD9F@theseventhson.freeserve.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Benny Prijono wrote: > > Hi all, > > Section 12.3.1 of the draft states that: > "To prevent loops, a server must check if its own address is > already contained in the Via header of the incoming request" > > Section 6.44.1 states that a 482 (Loop Detected) response MUST be > returned when a loop is detected. > > And finally, section 12.3 (last statement) states that a stateless proxy > forwards every request and response it received. > > Based on these statements, I think this is the correct behaviour for > stateless proxy: > 1. When the loop is detected, the stateless proxy will reply > with 482 (Loop Detected). > 2. The UAC then will send ACK. > 3. Proxy will forward ACK to the UAS. > 4. UAS will simply drop the ACK, maybe after complains loudly > about the invalid message. > > If this is the correct behaviour, then I'd like to know if there are any > ways to prevent the ACK to be received by the UAS. No. If the stateless proxy responds to the request, its not being a stateless proxy anymore. So, when it sends that 482, and receives an ACK, it doesn't forward the ACK. The ACK is for it. Its a similar problem to what happens when a proxy receives a request thats bad, and sends a 400 response. In this case, its not really acting like a stateless proxy for this request. Remember, stateful/stateless proxies are logic entities, and which role a real device takes can differ from request to request. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 01:21:50 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13624 for ; Wed, 1 Mar 2000 01:21:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CEA5D52DA; Wed, 1 Mar 2000 01:19:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3738352DC; Wed, 1 Mar 2000 01:19:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 9678A52DA for ; Wed, 1 Mar 2000 01:19:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 1 01:18:18 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 1 01:15:49 EST 2000 Received: from dynamicsoft.com (1Cust69.tnt2.freehold.nj.da.uu.net [63.17.114.69]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11337; Wed, 1 Mar 2000 01:18:25 -0500 (EST) Message-ID: <38BCB75C.5CE5A1FF@dynamicsoft.com> Date: Wed, 01 Mar 2000 01:23:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joshua Moloney Cc: "'sip@lists.research.bell-labs.com'" Subject: Re: Content-Encoding header (again) References: <61ABD11436FED21192440000F81F3E36033118B4@nwcwi1a.europe.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > Joshua Moloney wrote: > > In a SIP message with multiple payloads (i.e. multipart/mixed > content-type), the following example is often cited: > ..... > --unique-boundary-1 > Content-type:application/ISUP; version=ETSI1 > Content-Transfer-Encoding: binary > > 89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00 > > --unique-boundary-1-- > Indeed, draft-ietf-sip-isup-mime does use the Content-Transfer-Encoding in the example. I'm not sure its needed. Since SIP can carry the binary natively, I don't think we need it. My understanding was that if the native format for the Content-Type was binary, the data which followed was simply binary - no need to specify a transfer encoding. > The ISUP payload has a Content-Transfer-Encoding header. Is this > correct? Is it required at all (for the reasons stated in your > original response), or should the Content-Encoding header be used > instead? You don't need Content-Encoding unless some kind of optional transformation has been applied (like gzip). You should be able to send the binary directly without any kind of encodings. Or, should a parser be able to understand both types of > header (thus suggesting that a SIP parser should be fully MIME > compliant)? No, SIP uses a subset of MIME, same as http. I still believe we do not need Content-Transfer-Encoding, unless someone can give a compelling reason why.... -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 01:57:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16396 for ; Wed, 1 Mar 2000 01:57:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5371C52D6; Wed, 1 Mar 2000 01:55:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B83D852DD; Wed, 1 Mar 2000 01:55:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C696152D6 for ; Wed, 1 Mar 2000 01:55:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 01:53:14 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 1 01:50:45 EST 2000 Received: from dynamicsoft.com (1Cust69.tnt2.freehold.nj.da.uu.net [63.17.114.69]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11363; Wed, 1 Mar 2000 01:53:17 -0500 (EST) Message-ID: <38BCBF88.FAD553DA@dynamicsoft.com> Date: Wed, 01 Mar 2000 01:58:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Byerly Cc: sip@lists.research.bell-labs.com, rap@iphighway.com, herzog@iphighway.com, Burcak_Beser@3com.com Subject: Re: SIP/RSVP: How should the 183 be used? References: <38BC6866.DA4BD32C@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Comments inline below: Bryan Byerly wrote: > > ------------------ > SIP/RSVP message flow 1: > ------------------- > > SIP SIP SIP > GW Proxy GW > | | | > |--[1]INVITE----->| | > | | | > |<-[2]100---------| | > | |--[3]INVITE----->| 1 ott > | | | > | |<-[4]100---------| > | | | > 2 ott |<------[5]Path---------------------| > | | | > |-------[6]Resv-------------------->| 3 ott > | | | > 4 ott |<-[8]183---------|<-[7]183---------| > | | | > |-------[9]Path-------------------->| 5 ott > | | | > 6 ott |<------[10]Resv--------------------| > | | | > |--[11]PRACK(183)>|--[12]PRACK(183)>| 7 ott > | | ringing > | | | > 8 ott |<---[14]180------|<-[13]180--------| > ringback | | > | | | > | | off hook > |<---[16]200------|<-[15]200--------| > | | | > |----[17]ACK----->|--[18]ACK------->| > | | | > |<===============RTP===============>| > | | | > > > Event Triggered by: > [1] dialed digits > [2] [1] optional > [3] [1] > [4] [3] optional > [5] [3] > [6] [5] > [7] [6] > [8] [7] > [9] [8] > [10] [9] > [11] [10] > [12] [11] > [13] [12] > [14] [13] > [15] off hook > [16] [15] > [17] [16] > [18] [17] > > This triggering method incurs 8 one-way trip times (ott's) until > ringback. > > > > ------------------- > SIP/RSVP message flow 2: > ------------------- > > SIP SIP SIP > GW Proxy GW > | | | > |--[1]INVITE----->| | > | | | > |<-[2]100---------| | > | |--[3]INVITE----->| 1 ott --+ > | | | | > | |<-[4]100---------| <--------+ > | | | | > 2 ott |<-[6]183---------|<-[5]183---------| <--------+ > | | | | > |-------[7]Path-------------------->| 3 ott | > | | | | > 4 ott |<------[8]Resv---------------------| | > | | | | > |-------[9]ResvConfirm------------->| 5 ott | > | | | | > 2 ott |<------[10]Path--------------------| <-------+ > | | | > |-------[11]Resv------------------->| 3 ott > | | ringing > 6 ott |<-[13]180--------|<-[12]180--------| triggered by [9] & [11] > ringback | | > | | | > | | offhook > |<-[15]200--------|<-[14]200--------| > | | | > |--[16]ACK------->|--[17]ACK------->| > | | | > |<===============RTP===============>| > | | | > > > Event Triggered by: > [1] dialed digits > [2] [1] optional > [3] [1] > [4] [3] optional > [5] [3] > [6] [5] > [7] [6] > [8] [7] > [9] [8] > [10] [3] > [11] [10] > [12] [9] & [11] > [13] [12] > [14] offhook > [15] [14] > [16] [15] > [17] [16] > > This triggering method incurs 6 one-way trip times (ott's) until > ringback. > > > Discussion & Questions: > > So, flow 1 is sequential; whereas flow 2 has some parallelism. > Both flows are providing "assured QoS". They're not hugely different; (1) is relying on the PRACK to convey reservation confirmation, whereas (2) is using RSVP for this purpose. The problem in using PRACK for this purpose is that the 183 will be retransmitted until the PRACK comes. If you are delaying the PRACK waiting for reservation completion, lots of needless messages are sent. The fundamental problem is that PRACK meant for the sole purpose of acknowledging a provisional response. The overload in its meaning here is having an interaction with the reliability mechanism. > I recall reading in the RSVP RFC (RFC 2205, section 2.6, bullet 2) > that: > o The receipt of a ResvConf gives no guarantees. Assume the > first two reservation requests from receivers R1 and R2 > arrive at the node where they are merged. R2, whose > reservation was the second to arrive at that node, may > receive a ResvConf from that node while R1's request has > not > yet propagated all the way to a matching sender and may > still > fail. Thus, R2 may receive a ResvConf although there is no > > end-to-end reservation in place; furthermore, R2 may > receive > a ResvConf followed by a ResvErr. Reservation merging happens only for multicast. I don't think we are really considering that case here. The meaning of "don't ring until resources are reserved" only really has meaning in a point to point call. For something like an mbone session, I'm not sure how it works. Our original draft on the SDP/QoS preconditions actually talks about SAP usage, but I think there are issues with it. > 3) Does the 183 have any inherent meaning such as: > Flow of the 183 message implies the sender has already > established one-way QoS? (as shown in SIP/RSVP message flow 1)? > or conversely, 183 implies that the sender has not yet > establised one-way QoS? 183, according to draft-ietf-sip-183, has no meaning beyond "your session is proceeding". For the service DCS is trying to do, there needs to be some way for both sides to know the reservation is complete. It seems we have a few different call flows each with a different way to do this: 1. INFO method 2. PRACK/183 3. RESVCONF The tradeoffs, it seems, are relying on RSVP (in case 3) vs. building it into the application protocol (1 and 2), overloading existing mechanisms (in case 2) vs. having mechanisms specifically convey the confirmation (3 and also 1). -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 06:45:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28313 for ; Wed, 1 Mar 2000 06:45:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id ACE6952B6; Wed, 1 Mar 2000 06:43:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2316752C8; Wed, 1 Mar 2000 06:43:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8D27352B6 for ; Wed, 1 Mar 2000 06:43:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 06:41:29 EST 2000 Received: from qhars002.nortel.com ([192.100.101.19]) by dusty; Wed Mar 1 06:39:00 EST 2000 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Wed, 1 Mar 2000 11:41:04 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Mar 2000 11:41:03 -0000 Message-ID: <61ABD11436FED21192440000F81F3E36033118BB@nwcwi1a.europe.nortel.com> From: "Joshua Moloney" To: "'sip@lists.research.bell-labs.com'" Subject: Simultaneous transactions Date: Wed, 1 Mar 2000 11:40:54 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8373.055B462E" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF8373.055B462E Content-Type: text/plain Hi all, Is it legal to start a second transaction before the first is complete? Example: A INVITEs B to a session B responds with a 100 TRYING A sends an INFO to B (i.e. before the 200 & ACK messages have been sent regarding the original INVITE) I'd like to think that this scenario is not allowed. It would confuse the CSeq mechanism. Thanks, Josh Moloney Nortel Networks ------_=_NextPart_001_01BF8373.055B462E Content-Type: text/html Content-Transfer-Encoding: quoted-printable Simultaneous transactions

Hi all,

Is it legal to start a second = transaction before the first is complete?

Example:

A INVITEs B to a session
B responds with a 100 TRYING
A sends an INFO to B (i.e. before the = 200 & ACK messages have been sent regarding the original = INVITE)

I'd like to think that this scenario = is not allowed. It would confuse the CSeq mechanism.

Thanks,

Josh Moloney
Nortel Networks

------_=_NextPart_001_01BF8373.055B462E-- From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 07:23:21 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29082 for ; Wed, 1 Mar 2000 07:23:21 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 671E852AB; Wed, 1 Mar 2000 07:19:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D19D152D4; Wed, 1 Mar 2000 07:19:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3F6BA52AB for ; Wed, 1 Mar 2000 07:19:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 07:17:55 EST 2000 Received: from mail.mera.ru ([195.98.50.58]) by dusty; Wed Mar 1 07:15:26 EST 2000 Received: from mcseem.mera.ru (mcseem.mera.ru [195.98.57.12]) by mail.mera.ru (8.9.3/8.9.3) with ESMTP id PAA40848; Wed, 1 Mar 2000 15:17:47 +0300 (MSK) Date: Wed, 1 Mar 2000 15:21:29 +0300 From: "Stanislav S. Timinsky" X-Mailer: The Bat! (v1.36) S/N F29DEE5D / Educational Reply-To: "Stanislav S. Timinsky" Organization: MERA Labs. X-Priority: 3 (Normal) Message-ID: <9639.000301@mera.ru> To: sip@lists.research.bell-labs.com Cc: prj.men.sip@mera.ru Subject: Retransmission of response to OPTIONS-request Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Does anybody know, needed realize a retransmission of response to OPTIONS-request? If needed, when retransmission must be stopped? -- Best regards, Stanislav S. Timinsky mailto:timinsky@mera.ru Mera Labs. From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 07:27:24 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29152 for ; Wed, 1 Mar 2000 07:27:24 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E97FD52DA; Wed, 1 Mar 2000 07:23:54 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4CFCE52D4; Wed, 1 Mar 2000 07:23:52 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AA13152DA for ; Wed, 1 Mar 2000 07:23:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 07:21:31 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 1 07:19:00 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA01286; Wed, 1 Mar 2000 18:17:29 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256895.00434B9E ; Wed, 1 Mar 2000 17:45:02 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Joshua Moloney" Cc: "'sip@lists.research.bell-labs.com'" Message-ID: <65256895.00434AD1.00@sampark.hss.hns.com> Date: Wed, 1 Mar 2000 17:44:58 +0530 Subject: Re: Simultaneous transactions Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=OYGr0pOKF6GpdtknB5TFSqlSbgd11PnlHnYyJ4rbqiydix641n6gKmHq" Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --0__=OYGr0pOKF6GpdtknB5TFSqlSbgd11PnlHnYyJ4rbqiydix641n6gKmHq Content-type: text/plain; charset=us-ascii Content-Disposition: inline I think it depends on what the next transaction is. For invite, it must not. RFC2453bis states : " A UAC MUST NOT issue another INVITE request for the same call leg before the previous transaction has completed. A UAS that receives an INVITE before it sent the final response to an INVITE with a lower CSeq number MUST return a 400 (Bad Request) response and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds. A UA that receives an INVITE while it has an INVITE transaction pending, returns a 500 (Internal Server Error) and also includes a Retry-After header field." Thats that for INVITE only. However, it makes sense in cases like CANCEL when you send a CANCEL for an INVITE that has not recvd a final response yet. As far as INFO is concerned, well Im not sure how useful it would be, but I guess someone might find a need to send some message encapsulated in an INFO to the recipient, since it is just an INFOrmational message. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Joshua Moloney" on 03/01/2000 05:10:54 PM To: "'sip@lists.research.bell-labs.com'" cc: Subject: Simultaneous transactions Hi all, Is it legal to start a second transaction before the first is complete? Example: A INVITEs B to a session B responds with a 100 TRYING A sends an INFO to B (i.e. before the 200 & ACK messages have been sent regarding the original INVITE) I'd like to think that this scenario is not allowed. It would confuse the CSeq mechanism. Thanks, Josh Moloney Nortel Networks --0__=OYGr0pOKF6GpdtknB5TFSqlSbgd11PnlHnYyJ4rbqiydix641n6gKmHq Content-type: text/html; name="att-1.htm" Content-Disposition: attachment; filename="att-1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTEuNjUiPg0KPFRJVExFPlNpbXVsdGFu ZW91cyB0cmFuc2FjdGlvbnM8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJ WkU9MiBGQUNFPSJBcmlhbCI+SGkgYWxsLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y IEZBQ0U9IkFyaWFsIj5JcyBpdCBsZWdhbCB0byBzdGFydCBhIHNlY29uZCB0cmFuc2FjdGlvbiBi ZWZvcmUgdGhlIGZpcnN0IGlzIGNvbXBsZXRlPzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0la RT0yIEZBQ0U9IkFyaWFsIj5FeGFtcGxlOjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y IEZBQ0U9IkFyaWFsIj5BIElOVklURXMgQiB0byBhIHNlc3Npb248L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yIEZBQ0U9IkFyaWFsIj5CIHJlc3BvbmRzIHdpdGggYSAxMDAgVFJZSU5HPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QSBzZW5kcyBhbiBJTkZPIHRvIEIgKGkuZS4g YmVmb3JlIHRoZSAyMDAgJmFtcDsgQUNLIG1lc3NhZ2VzIGhhdmUgYmVlbiBzZW50IHJlZ2FyZGlu ZyB0aGUgb3JpZ2luYWwgSU5WSVRFKTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZB Q0U9IkFyaWFsIj5JJ2QgbGlrZSB0byB0aGluayB0aGF0IHRoaXMgc2NlbmFyaW8gaXMgbm90IGFs bG93ZWQuIEl0IHdvdWxkIGNvbmZ1c2UgdGhlIENTZXEgbWVjaGFuaXNtLjwvRk9OVD4NCjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGFua3MsPC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkpvc2ggTW9sb25leTwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTIgRkFDRT0iQXJpYWwiPk5vcnRlbCBOZXR3b3JrczwvRk9OVD4NCjwvUD4NCg0KPC9C T0RZPg0KPC9IVE1MPg== --0__=OYGr0pOKF6GpdtknB5TFSqlSbgd11PnlHnYyJ4rbqiydix641n6gKmHq-- From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 07:30:39 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29186 for ; Wed, 1 Mar 2000 07:30:39 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9B60A52DD; Wed, 1 Mar 2000 07:24:02 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AD5C352DB; Wed, 1 Mar 2000 07:23:54 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6316052DB for ; Wed, 1 Mar 2000 07:23:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 07:22:05 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 1 07:19:32 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA00828; Wed, 1 Mar 2000 18:11:14 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256895.00434B9E ; Wed, 1 Mar 2000 17:45:02 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Joshua Moloney" Cc: "'sip@lists.research.bell-labs.com'" Message-ID: <65256895.00434AD1.00@sampark.hss.hns.com> Date: Wed, 1 Mar 2000 17:44:58 +0530 Subject: Re: Simultaneous transactions Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=OYGr0pOKF6GpdtknB5TFSqlSbgd11PnlHnYyJ4rbqiydix641n6gKmHq" Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --0__=OYGr0pOKF6GpdtknB5TFSqlSbgd11PnlHnYyJ4rbqiydix641n6gKmHq Content-type: text/plain; charset=us-ascii Content-Disposition: inline I think it depends on what the next transaction is. For invite, it must not. RFC2453bis states : " A UAC MUST NOT issue another INVITE request for the same call leg before the previous transaction has completed. A UAS that receives an INVITE before it sent the final response to an INVITE with a lower CSeq number MUST return a 400 (Bad Request) response and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds. A UA that receives an INVITE while it has an INVITE transaction pending, returns a 500 (Internal Server Error) and also includes a Retry-After header field." Thats that for INVITE only. However, it makes sense in cases like CANCEL when you send a CANCEL for an INVITE that has not recvd a final response yet. As far as INFO is concerned, well Im not sure how useful it would be, but I guess someone might find a need to send some message encapsulated in an INFO to the recipient, since it is just an INFOrmational message. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Joshua Moloney" on 03/01/2000 05:10:54 PM To: "'sip@lists.research.bell-labs.com'" cc: Subject: Simultaneous transactions Hi all, Is it legal to start a second transaction before the first is complete? Example: A INVITEs B to a session B responds with a 100 TRYING A sends an INFO to B (i.e. before the 200 & ACK messages have been sent regarding the original INVITE) I'd like to think that this scenario is not allowed. It would confuse the CSeq mechanism. Thanks, Josh Moloney Nortel Networks --0__=OYGr0pOKF6GpdtknB5TFSqlSbgd11PnlHnYyJ4rbqiydix641n6gKmHq Content-type: text/html; name="att-1.htm" Content-Disposition: attachment; filename="att-1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTEuNjUiPg0KPFRJVExFPlNpbXVsdGFu ZW91cyB0cmFuc2FjdGlvbnM8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJ WkU9MiBGQUNFPSJBcmlhbCI+SGkgYWxsLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y IEZBQ0U9IkFyaWFsIj5JcyBpdCBsZWdhbCB0byBzdGFydCBhIHNlY29uZCB0cmFuc2FjdGlvbiBi ZWZvcmUgdGhlIGZpcnN0IGlzIGNvbXBsZXRlPzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0la RT0yIEZBQ0U9IkFyaWFsIj5FeGFtcGxlOjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y IEZBQ0U9IkFyaWFsIj5BIElOVklURXMgQiB0byBhIHNlc3Npb248L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yIEZBQ0U9IkFyaWFsIj5CIHJlc3BvbmRzIHdpdGggYSAxMDAgVFJZSU5HPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QSBzZW5kcyBhbiBJTkZPIHRvIEIgKGkuZS4g YmVmb3JlIHRoZSAyMDAgJmFtcDsgQUNLIG1lc3NhZ2VzIGhhdmUgYmVlbiBzZW50IHJlZ2FyZGlu ZyB0aGUgb3JpZ2luYWwgSU5WSVRFKTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZB Q0U9IkFyaWFsIj5JJ2QgbGlrZSB0byB0aGluayB0aGF0IHRoaXMgc2NlbmFyaW8gaXMgbm90IGFs bG93ZWQuIEl0IHdvdWxkIGNvbmZ1c2UgdGhlIENTZXEgbWVjaGFuaXNtLjwvRk9OVD4NCjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGFua3MsPC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkpvc2ggTW9sb25leTwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTIgRkFDRT0iQXJpYWwiPk5vcnRlbCBOZXR3b3JrczwvRk9OVD4NCjwvUD4NCg0KPC9C T0RZPg0KPC9IVE1MPg== --0__=OYGr0pOKF6GpdtknB5TFSqlSbgd11PnlHnYyJ4rbqiydix641n6gKmHq-- From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 07:39:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29545 for ; Wed, 1 Mar 2000 07:39:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AF20652D5; Wed, 1 Mar 2000 07:37:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2BE1B52D6; Wed, 1 Mar 2000 07:37:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id E372952D5 for ; Wed, 1 Mar 2000 07:37:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 1 07:36:12 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 1 07:33:42 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA01966; Wed, 1 Mar 2000 18:31:42 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256895.004524C1 ; Wed, 1 Mar 2000 18:05:13 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Stanislav S. Timinsky" Cc: sip@lists.research.bell-labs.com, prj.men.sip@mera.ru Message-ID: <65256895.004523BE.00@sampark.hss.hns.com> Date: Wed, 1 Mar 2000 18:05:10 +0530 Subject: Re: Retransmission of response to OPTIONS-request Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, the RFC states the conditions same as BYE. Refer to section 10.4 Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Stanislav S. Timinsky" on 03/01/2000 05:51:29 PM Please respond to "Stanislav S. Timinsky" To: sip@lists.research.bell-labs.com cc: prj.men.sip@mera.ru Subject: Retransmission of response to OPTIONS-request Hello, Does anybody know, needed realize a retransmission of response to OPTIONS-request? If needed, when retransmission must be stopped? -- Best regards, Stanislav S. Timinsky mailto:timinsky@mera.ru Mera Labs. From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 07:51:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29743 for ; Wed, 1 Mar 2000 07:51:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EDD9152D6; Wed, 1 Mar 2000 07:49:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4E37552DB; Wed, 1 Mar 2000 07:49:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id E5FB752D6 for ; Wed, 1 Mar 2000 07:49:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 1 07:47:38 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 1 07:45:08 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA02780; Wed, 1 Mar 2000 18:43:17 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256895.00463245 ; Wed, 1 Mar 2000 18:16:43 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: archow@hns.com Cc: "Stanislav S. Timinsky" , sip@lists.research.bell-labs.com, prj.men.sip@mera.ru Message-ID: <65256895.00463183.00@sampark.hss.hns.com> Date: Wed, 1 Mar 2000 18:16:41 +0530 Subject: Re: Retransmission of response to OPTIONS-request Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Oops - I think you asked for retransmission of *responses* to OPTIONS ? Final responses to OPTIONS does not need retransmission as the request itself will be retransmitted If you generally want to send reliable *provisional* responses then refer to the reliableprovision draft -though I dont think you will need it for OPTIONS. Regds Arjun archow@hns.com on 03/01/2000 06:05:10 PM To: "Stanislav S. Timinsky" cc: sip@lists.research.bell-labs.com, prj.men.sip@mera.ru Subject: Re: Retransmission of response to OPTIONS-request Hi, the RFC states the conditions same as BYE. Refer to section 10.4 Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Stanislav S. Timinsky" on 03/01/2000 05:51:29 PM Please respond to "Stanislav S. Timinsky" To: sip@lists.research.bell-labs.com cc: prj.men.sip@mera.ru Subject: Retransmission of response to OPTIONS-request Hello, Does anybody know, needed realize a retransmission of response to OPTIONS-request? If needed, when retransmission must be stopped? -- Best regards, Stanislav S. Timinsky mailto:timinsky@mera.ru Mera Labs. From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 08:48:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01091 for ; Wed, 1 Mar 2000 08:48:07 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B6B2952D4; Wed, 1 Mar 2000 08:45:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 26A8B52DC; Wed, 1 Mar 2000 08:45:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7335B52D4 for ; Wed, 1 Mar 2000 08:45:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 08:43:49 EST 2000 Received: from cmailg4.svr.pol.co.uk ([195.92.195.174]) by dusty; Wed Mar 1 08:41:20 EST 2000 Received: from modem-183.domino-damsel.dialup.pol.co.uk ([62.136.255.183] helo=theseventhson.freeserve.co.uk) by cmailg4.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12Q9Pm-0004pD-00; Wed, 01 Mar 2000 13:43:46 +0000 Message-ID: <38BD1EC0.54E50471@theseventhson.freeserve.co.uk> Date: Wed, 01 Mar 2000 13:44:32 +0000 From: Benny Prijono X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "sip@lists.research.bell-labs.com" Subject: Re: Loop detection in Invite request in stateless proxy References: <38BBF521.C450DD9F@theseventhson.freeserve.co.uk> <38BCB3FE.1E0803C1@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > -deleted. > > Remember, stateful/stateless proxies are logic entities, and which role > a real device takes can differ from request to request. > Ah, that's it! Seems that although I've re-read the RFC at least 2-3 times, still I missed this concept, badly.. ;) Thanks. -- cheers, Bennylp From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 09:56:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03520 for ; Wed, 1 Mar 2000 09:56:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5B6DD52C8; Wed, 1 Mar 2000 09:53:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C946152DB; Wed, 1 Mar 2000 09:53:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 20CB652C8 for ; Wed, 1 Mar 2000 09:53:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 09:51:39 EST 2000 Received: from ns-inetext.inet.com ([199.171.211.140]) by dusty; Wed Mar 1 09:49:10 EST 2000 Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com (8.9.2/8.9.2) with ESMTP id IAA23247 for ; Wed, 1 Mar 2000 08:50:21 -0600 (CST) Received: from inet.com ([172.16.63.55]) by harpo.inetint.com (Netscape Messaging Server 3.6) with ESMTP id AAAB4B; Wed, 1 Mar 2000 08:55:47 -0600 Message-ID: <38BD2E56.5662E965@inet.com> Date: Wed, 01 Mar 2000 08:51:03 -0600 From: Nathan Nelson X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Cc: sip@lists.research.bell-labs.com Subject: Re: Information request! (Billing Package?) References: <4FBEA8857476D311A03300204840E1CF32E9FC@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The point that was being ask is not specific to SIP, but more general to a decomposed architectures. The current formats that are used to bill PSTN traffic are based on AMA BAF or a carrier/vendor defined CDR. Inet believes there is a need to build a standard format for a Transaction over IP record that allows for elements and parameters to be recorded. Some of the key components of this record could be: A Tracking field to tie multiple records from multiple platforms together Time Stamps Usage Stamps Originating Information (PSTN Number, IP address, email address.....) Terminating Information (PSTN Number, IP address, email address....) Terminating Port/ Media Gateway Originating Port/Media Gateway Amount of bandwidth used Types of Applications used Premiums associated with Applications Application Information (Application server IP addresses) Intermediate network usage One of the basic issues with a decomposed architecture from an accounting aspect is that multiple devices are involved in call set, routing, application usage, signaling, and finally termination. It would be nice to see IETF support a group that looks at accountability and billing, or at least provide a basic model to build such records. Thx, Nate Nelson Inet "Rosen, Brian" wrote: > Interesting, I assumed everything EXCEPT a gateway throws CDRs. > Assuming a decomposed gateway, the GW feeds statistics to a Call Agent > (which would be a SIP UA among other things) that throws CDRs. > > The billing system collates all the CDRs. > > The spec required is, of course, the format of the CDR and the way they > are transported. You could claim that a "transaction log" is a form of > CDR I suppose. > > I'd certainly agree that SIP itself doesn't have any "billing package". > A UA and a server might, but that is independent of the protocol. Billing > might very well impact some things in SIP. > > Brian > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@wcom.com] > > Sent: Tuesday, February 29, 2000 2:41 PM > > To: Mart Nurmet; sip@lists.research.bell-labs.com > > Subject: RE: Information request! (Billing Package?) > > > > > > What would a billing package look like? I've never really > > understood the > > concept, and it might be useful to talk about it some more. > > > > Here's how some implementors are doing it: > > > > 1) Gateways throw CDRs using RADIUS or something similar. > > This feeds into > > rating, reporting, and billing systems, > > > > 2) SIP servers record transaction logs. These may feed into rating and > > billing systems, and probably feed into reporting systems. > > > > 3) QoS PEP and PDPs log resource usages. These feed upstream as well. > > > > 4) Other systems, like profile managers, report usage. > > > > 5) Rating, reporting, and billing systems sift thru the vast > > amounts of > > information coming at them and make useful things happen. > > > > All of these things use other protocols and systems -- they aren't SIP > > specific. They do rely on SIP functions like authentication > > -- that is, the > > goal of achieving billing functions has driven some > > requirements into the > > design of SIP. However, other than driving some requirements > > to SIP, such > > efforts are generally considered to be outside the scope of > > the SIP WG. > > > > Are you perhaps proposing to add functionality to SIP to > > simplify or enhance > > reporting capabilities or to simplify the task of driving > > downstream billing > > systems? > > > > -- > > Dena > > > -----Original Message----- > > > From: owner-sip@lists.research.bell-labs.com > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of > > Mart Nurmet > > > Sent: Monday, February 28, 2000 2:24 PM > > > To: sip@lists.research.bell-labs.com > > > Subject: Information request! (Billing Package?) > > > > > > > > > I am looking for information if there has been any work > > done to generate a > > > billing package for SIP. From my look at the available > > > information there does > > > not seem to be any. Is that the case or am I missing something? > > > > > > Thank you, > > > -Mart > > > > > > > > > > From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 11:00:33 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06022 for ; Wed, 1 Mar 2000 11:00:24 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 71C4D52DB; Wed, 1 Mar 2000 10:57:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BE9B852DE; Wed, 1 Mar 2000 10:57:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 78A8952DB for ; Wed, 1 Mar 2000 10:57:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 10:56:19 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Wed Mar 1 10:53:49 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA24489; Wed, 1 Mar 2000 10:56:11 -0500 (EST) Message-ID: <38BD3D9A.574C12D2@cisco.com> Date: Wed, 01 Mar 2000 10:56:11 -0500 From: Manoj Bhatia Organization: Cisco Systems, RTP, NC, USA. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Bryan Byerly , sip@lists.research.bell-labs.com, rap@iphighway.com, herzog@iphighway.com, Burcak_Beser@3com.com Subject: Re: SIP/RSVP: How should the 183 be used? References: <38BC6866.DA4BD32C@cisco.com> <38BCBF88.FAD553DA@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------D57047EA5E9E262548CCB62E" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------D57047EA5E9E262548CCB62E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Your comment about 183 clearly says "according to draft-ietf-sip-183, has no meaning beyond "your session is proceeding". However, we do have provisions for QoS and Security as Session Headers for 183. In fact the drafts says that header value of QoS can be used to establish QoS relationship between caller and callee. How does all that fit into the question Bryan raised ? thanks -manoj Jonathan Rosenberg wrote: > Comments inline below: > > Bryan Byerly wrote: > > > > ------------------ > > SIP/RSVP message flow 1: > > ------------------- > > > > SIP SIP SIP > > GW Proxy GW > > | | | > > |--[1]INVITE----->| | > > | | | > > |<-[2]100---------| | > > | |--[3]INVITE----->| 1 ott > > | | | > > | |<-[4]100---------| > > | | | > > 2 ott |<------[5]Path---------------------| > > | | | > > |-------[6]Resv-------------------->| 3 ott > > | | | > > 4 ott |<-[8]183---------|<-[7]183---------| > > | | | > > |-------[9]Path-------------------->| 5 ott > > | | | > > 6 ott |<------[10]Resv--------------------| > > | | | > > |--[11]PRACK(183)>|--[12]PRACK(183)>| 7 ott > > | | ringing > > | | | > > 8 ott |<---[14]180------|<-[13]180--------| > > ringback | | > > | | | > > | | off hook > > |<---[16]200------|<-[15]200--------| > > | | | > > |----[17]ACK----->|--[18]ACK------->| > > | | | > > |<===============RTP===============>| > > | | | > > > > > > Event Triggered by: > > [1] dialed digits > > [2] [1] optional > > [3] [1] > > [4] [3] optional > > [5] [3] > > [6] [5] > > [7] [6] > > [8] [7] > > [9] [8] > > [10] [9] > > [11] [10] > > [12] [11] > > [13] [12] > > [14] [13] > > [15] off hook > > [16] [15] > > [17] [16] > > [18] [17] > > > > This triggering method incurs 8 one-way trip times (ott's) until > > ringback. > > > > > > > > ------------------- > > SIP/RSVP message flow 2: > > ------------------- > > > > SIP SIP SIP > > GW Proxy GW > > | | | > > |--[1]INVITE----->| | > > | | | > > |<-[2]100---------| | > > | |--[3]INVITE----->| 1 ott --+ > > | | | | > > | |<-[4]100---------| <--------+ > > | | | | > > 2 ott |<-[6]183---------|<-[5]183---------| <--------+ > > | | | | > > |-------[7]Path-------------------->| 3 ott | > > | | | | > > 4 ott |<------[8]Resv---------------------| | > > | | | | > > |-------[9]ResvConfirm------------->| 5 ott | > > | | | | > > 2 ott |<------[10]Path--------------------| <-------+ > > | | | > > |-------[11]Resv------------------->| 3 ott > > | | ringing > > 6 ott |<-[13]180--------|<-[12]180--------| triggered by [9] & [11] > > ringback | | > > | | | > > | | offhook > > |<-[15]200--------|<-[14]200--------| > > | | | > > |--[16]ACK------->|--[17]ACK------->| > > | | | > > |<===============RTP===============>| > > | | | > > > > > > Event Triggered by: > > [1] dialed digits > > [2] [1] optional > > [3] [1] > > [4] [3] optional > > [5] [3] > > [6] [5] > > [7] [6] > > [8] [7] > > [9] [8] > > [10] [3] > > [11] [10] > > [12] [9] & [11] > > [13] [12] > > [14] offhook > > [15] [14] > > [16] [15] > > [17] [16] > > > > This triggering method incurs 6 one-way trip times (ott's) until > > ringback. > > > > > > Discussion & Questions: > > > > So, flow 1 is sequential; whereas flow 2 has some parallelism. > > Both flows are providing "assured QoS". > > They're not hugely different; (1) is relying on the PRACK to convey > reservation confirmation, whereas (2) is using RSVP for this purpose. > The problem in using PRACK for this purpose is that the 183 will be > retransmitted until the PRACK comes. If you are delaying the PRACK > waiting for reservation completion, lots of needless messages are sent. > The fundamental problem is that PRACK meant for the sole purpose of > acknowledging a provisional response. The overload in its meaning here > is having an interaction with the reliability mechanism. > > > I recall reading in the RSVP RFC (RFC 2205, section 2.6, bullet 2) > > that: > > o The receipt of a ResvConf gives no guarantees. Assume the > > first two reservation requests from receivers R1 and R2 > > arrive at the node where they are merged. R2, whose > > reservation was the second to arrive at that node, may > > receive a ResvConf from that node while R1's request has > > not > > yet propagated all the way to a matching sender and may > > still > > fail. Thus, R2 may receive a ResvConf although there is no > > > > end-to-end reservation in place; furthermore, R2 may > > receive > > a ResvConf followed by a ResvErr. > > Reservation merging happens only for multicast. I don't think we are > really considering that case here. The meaning of "don't ring until > resources are reserved" only really has meaning in a point to point > call. For something like an mbone session, I'm not sure how it works. > Our original draft on the SDP/QoS preconditions actually talks about SAP > usage, but I think there are issues with it. > > > 3) Does the 183 have any inherent meaning such as: > > Flow of the 183 message implies the sender has already > > established one-way QoS? (as shown in SIP/RSVP message flow 1)? > > or conversely, 183 implies that the sender has not yet > > establised one-way QoS? > > > > > For the service DCS is trying to do, there needs to be some way for both > sides to know the reservation is complete. It seems we have a few > different call flows each with a different way to do this: > > 1. INFO method > 2. PRACK/183 > 3. RESVCONF > > The tradeoffs, it seems, are relying on RSVP (in case 3) vs. building it > into the application protocol (1 and 2), overloading existing mechanisms > (in case 2) vs. having mechanisms specifically convey the confirmation > (3 and also 1). > > -Jonathan R. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- Manoj Bhatia | | | manojb@cisco.com | :|: :|: 7025 Kit Creek Road, P.O. Box 14987 | :|||||: :|||||: Research Triangle Park, NC 27709 | .:|||||||:.:|||||||:. 919-392-3873 fax: 919-392-6801 | C i s c o S y s t e m s --------------D57047EA5E9E262548CCB62E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Jonathan

Your comment about 183 clearly says
"according to draft-ietf-sip-183, has no meaning beyond "your
session is proceeding".

However, we do have provisions for QoS and Security as Session Headers
for 183. In fact the drafts says that header value of QoS can be used to establish QoS
relationship between caller and callee.

How does all that fit into the question Bryan raised ?

thanks
-manoj

Jonathan Rosenberg wrote:

Comments inline below:

Bryan Byerly wrote:
>
> ------------------
> SIP/RSVP message flow 1:
> -------------------
>
>       SIP               SIP               SIP
>       GW                Proxy             GW
>        |                 |                 |
>        |--[1]INVITE----->|                 |
>        |                 |                 |
>        |<-[2]100---------|                 |
>        |                 |--[3]INVITE----->|  1 ott
>        |                 |                 |
>        |                 |<-[4]100---------|
>        |                 |                 |
>  2 ott |<------[5]Path---------------------|
>        |                 |                 |
>        |-------[6]Resv-------------------->|  3 ott
>        |                 |                 |
>  4 ott |<-[8]183---------|<-[7]183---------|
>        |                 |                 |
>        |-------[9]Path-------------------->|  5 ott
>        |                 |                 |
>  6 ott |<------[10]Resv--------------------|
>        |                 |                 |
>        |--[11]PRACK(183)>|--[12]PRACK(183)>|  7 ott
>        |                 |              ringing
>        |                 |                 |
>  8 ott |<---[14]180------|<-[13]180--------|
>     ringback             |                 |
>        |                 |                 |
>        |                 |              off hook
>        |<---[16]200------|<-[15]200--------|
>        |                 |                 |
>        |----[17]ACK----->|--[18]ACK------->|
>        |                 |                 |
>        |<===============RTP===============>|
>        |                 |                 |
>
>
> Event   Triggered by:
> [1]     dialed digits
> [2]     [1]  optional
> [3]     [1]
> [4]     [3]  optional
> [5]     [3]
> [6]     [5]
> [7]     [6]
> [8]     [7]
> [9]     [8]
> [10]    [9]
> [11]    [10]
> [12]    [11]
> [13]    [12]
> [14]    [13]
> [15]    off hook
> [16]    [15]
> [17]    [16]
> [18]    [17]
>
> This triggering method incurs 8 one-way trip times (ott's) until
> ringback.
>
>
>
> -------------------
> SIP/RSVP message flow 2:
> -------------------
>
>       SIP               SIP               SIP
>       GW                Proxy             GW
>        |                 |                 |
>        |--[1]INVITE----->|                 |
>        |                 |                 |
>        |<-[2]100---------|                 |
>        |                 |--[3]INVITE----->|  1 ott  --+
>        |                 |                 |           |
>        |                 |<-[4]100---------|  <--------+
>        |                 |                 |           |
>  2 ott |<-[6]183---------|<-[5]183---------|  <--------+
>        |                 |                 |           |
>        |-------[7]Path-------------------->|  3 ott    |
>        |                 |                 |           |
>  4 ott |<------[8]Resv---------------------|           |
>        |                 |                 |           |
>        |-------[9]ResvConfirm------------->|  5 ott    |
>        |                 |                 |           |
>  2 ott |<------[10]Path--------------------|   <-------+
>        |                 |                 |
>        |-------[11]Resv------------------->|  3 ott
>        |                 |              ringing
>  6 ott |<-[13]180--------|<-[12]180--------|  triggered by [9] & [11]
>      ringback            |                 |
>        |                 |                 |
>        |                 |              offhook
>        |<-[15]200--------|<-[14]200--------|
>        |                 |                 |
>        |--[16]ACK------->|--[17]ACK------->|
>        |                 |                 |
>        |<===============RTP===============>|
>        |                 |                 |
>
>
> Event   Triggered by:
> [1]     dialed digits
> [2]     [1]  optional
> [3]     [1]
> [4]     [3]  optional
> [5]     [3]
> [6]     [5]
> [7]     [6]
> [8]     [7]
> [9]     [8]
> [10]    [3]
> [11]    [10]
> [12]    [9] & [11]
> [13]    [12]
> [14]    offhook
> [15]    [14]
> [16]    [15]
> [17]    [16]
>
> This triggering method incurs 6 one-way trip times (ott's) until
> ringback.
>
>
> Discussion & Questions:
>
> So, flow 1 is sequential; whereas flow 2 has some parallelism.
> Both flows are providing "assured QoS".

They're not hugely different; (1) is relying on the PRACK to convey
reservation confirmation, whereas (2) is using RSVP for this purpose.
The problem in using PRACK for this purpose is that the 183 will be
retransmitted until the PRACK comes. If you are delaying the PRACK
waiting for reservation completion, lots of needless messages are sent.
The fundamental problem is that PRACK meant for the sole purpose of
acknowledging a provisional response. The overload in its meaning here
is having an interaction with the reliability mechanism.

> I recall reading in the RSVP RFC (RFC 2205, section 2.6, bullet 2)
> that:
>       o    The receipt of a ResvConf gives no guarantees.  Assume the
>            first two reservation requests from receivers R1 and R2
>            arrive at the node where they are merged.  R2, whose
>            reservation was the second to arrive at that node, may
>            receive a ResvConf from that node while R1's request has
> not
>            yet propagated all the way to a matching sender and may
> still
>            fail.  Thus, R2 may receive a ResvConf although there is no
>
>            end-to-end reservation in place; furthermore, R2 may
> receive
>            a ResvConf followed by a ResvErr.

Reservation merging happens only for multicast. I don't think we are
really considering that case here. The meaning of "don't ring until
resources are reserved" only really has meaning in a point to point
call. For something like an mbone session, I'm not sure how it works.
Our original draft on the SDP/QoS preconditions actually talks about SAP
usage, but I think there are issues with it.

> 3) Does the 183 have any inherent meaning such as:
>     Flow of the 183 message implies the sender has already
>     established one-way QoS? (as shown in SIP/RSVP message flow 1)?
>     or conversely, 183 implies that the sender has not yet
>     establised one-way QoS?
 
 

 

For the service DCS is trying to do, there needs to be some way for both
sides to know the reservation is complete. It seems we have a few
different call flows each with a different way to do this:

1. INFO method
2. PRACK/183
3. RESVCONF

The tradeoffs, it seems, are relying on RSVP (in case 3) vs. building it
into the application protocol (1 and 2), overloading existing mechanisms
(in case 2) vs. having mechanisms specifically convey the confirmation
(3 and also 1).

-Jonathan R.

--
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

-- 
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, P.O. Box 14987    |     :|||||:   :|||||:
Research Triangle Park, NC 27709       |   .:|||||||:.:|||||||:.
919-392-3873      fax: 919-392-6801    |  C i s c o S y s t e m s
  --------------D57047EA5E9E262548CCB62E-- From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 11:24:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06791 for ; Wed, 1 Mar 2000 11:24:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 787BF52DE; Wed, 1 Mar 2000 11:21:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F03DE52DF; Wed, 1 Mar 2000 11:21:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F110452DE for ; Wed, 1 Mar 2000 11:21:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 11:20:20 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Wed Mar 1 11:17:50 EST 2000 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA10172; Wed, 1 Mar 2000 10:20:11 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA24443; Wed, 1 Mar 2000 10:20:11 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA14944; Wed, 1 Mar 2000 10:20:10 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA09142; Wed, 1 Mar 2000 10:20:09 -0600 (CST) Message-Id: <200003011620.KAA09142@b04a24.exu.ericsson.se> Subject: Re: SRV records To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Date: Wed, 1 Mar 2000 10:20:09 -0600 (CST) Cc: sip@lists.research.bell-labs.com In-Reply-To: <38BAB38F.C3EC9A26@cs.columbia.edu> from "Henning Schulzrinne" at Feb 28, 2000 12:42:39 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >Now that SRV records are a Proposed Standard (RFC 2782), I would suggest >simplifying the lookup procedure to include SRV as SHOULD rather than as >an optional procedure. This does not force modifying DNS to include SRV >records, but does encourage implementation of SRV in SIP clients. > >Comments? I agree. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 12:09:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08212 for ; Wed, 1 Mar 2000 12:09:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CC89652DC; Wed, 1 Mar 2000 12:07:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4FF3152E0; Wed, 1 Mar 2000 12:07:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 712FB52DC for ; Wed, 1 Mar 2000 12:07:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 1 12:06:45 EST 2000 Received: from atlrel2.hp.com ([156.153.255.202]) by dusty; Wed Mar 1 12:04:17 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel2.hp.com (Postfix) with ESMTP id 68948290E for ; Wed, 1 Mar 2000 12:07:13 -0500 (EST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id RAA15942 for ; Wed, 1 Mar 2000 17:06:41 GMT Message-ID: <38BD4E35.9DEFEEC0@hplb.hpl.hp.com> Date: Wed, 01 Mar 2000 17:07:01 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Cc: sip@lists.research.bell-labs.com Subject: Re: SRV records References: <200003011620.KAA09142@b04a24.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Adam B. Roach" wrote: > > >Now that SRV records are a Proposed Standard (RFC 2782), I would suggest > >simplifying the lookup procedure to include SRV as SHOULD rather than as > >an optional procedure. This does not force modifying DNS to include SRV > >records, but does encourage implementation of SRV in SIP clients. > > > >Comments? > > I agree. ditto. -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 13:46:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10334 for ; Wed, 1 Mar 2000 13:46:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 024B952E0; Wed, 1 Mar 2000 13:43:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 749DA52E1; Wed, 1 Mar 2000 13:43:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 67E1E52E0 for ; Wed, 1 Mar 2000 13:43:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 13:42:32 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Mar 1 13:40:03 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA17908; Wed, 1 Mar 2000 13:42:27 -0500 (EST) Message-ID: <38BD6491.5BA1E6A0@cs.columbia.edu> Date: Wed, 01 Mar 2000 13:42:25 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Cc: Terri Cali Subject: SIP bakeoff registration now open Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit http://www.sipbakeoff.org/4/ has details. Please contact Terri Cali (cc'ed) with any questions. I look forward to seeing many of you at the bake-off. I'd also appreciate feedback on whether and to what extent we should test more formally for RTP interoperability at this event. This has become an issue as we cannot progress RTP to draft status without more implementations that comply. Since a phone that only rings but doesn't "talk" is of somewhat limited use, this might be of some interest. (This would obviously only affect UAs, not servers.) Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 13:58:15 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10508 for ; Wed, 1 Mar 2000 13:58:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6821252E1; Wed, 1 Mar 2000 13:55:35 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BFC1152E4; Wed, 1 Mar 2000 13:55:34 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 8904252E1 for ; Wed, 1 Mar 2000 13:55:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 1 13:53:53 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Wed Mar 1 13:51:24 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQR002JCB4PBB@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 1 Mar 2000 18:53:14 +0000 (GMT) Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id SAA15562; Wed, 01 Mar 2000 18:53:32 +0000 (GMT) Received: from dwillispc8 ([166.35.225.166]) by omta1.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000301185212.QDXT1802@dwillispc8>; Wed, 01 Mar 2000 12:52:12 -0600 Date: Wed, 01 Mar 2000 12:52:05 -0600 From: Dean Willis Subject: DHCP options for SIP, Last Call Details In-reply-to: <38B4D36E.329DE08A@dynamicsoft.com> To: Jonathan Rosenberg , sip@lists.research.bell-labs.com Cc: droms@bucknell.edu Message-id: <000001bf83af$3cf26fe0$a6e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The DHCP group has scheduled the last call for draft-nair-sip-dhcp-01.txt in the DHCP WG to close on March 17. This seems reasonable, so I suggest we adopt the same date. This is consistent with the "three weeks" time frame given in Jonathan's last call, copied below. > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Jonathan > Rosenberg > Sent: Thursday, February 24, 2000 12:45 AM > To: sip@lists.research.bell-labs.com > Cc: droms@bucknell.edu > Subject: DHCP > > > Folks, > > There has been some discussion in response to our proposal to fast track > a DHCP option for SIP. This discussion generally indicated that DHCP > would not be sufficient for autoconfiguration. We (the wg chairs) think > a DHCP option for finding a default proxy is a useful thing, even > if it is not a complete solution. We therefore propose to define the > DHCP > option, making it available for implementation, and carry on the dialog > on > managing SIP endpoints as a continuing thread. > > As such, this message will serve as a working group last call on the > DHCP options document: > http://search.ietf.org/internet-drafts/draft-nair-sip-dhcp-01.txt > > We are trying to coordinate a parallel last call on the dhcp list, which > must review the document as well. > > The working group last call will last three weeks. Please send comments > to the list or to the authors during this time. > > Thanks, > Jonathan R. > > > > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 15:34:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12471 for ; Wed, 1 Mar 2000 15:34:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1805552E3; Wed, 1 Mar 2000 15:31:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6C97C52E5; Wed, 1 Mar 2000 15:31:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E505F52E3 for ; Wed, 1 Mar 2000 15:31:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 15:29:31 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Wed Mar 1 15:27:03 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FQR00AMXFKWQ8@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 1 Mar 2000 20:29:20 +0000 (GMT) Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id UAA04081; Wed, 01 Mar 2000 20:28:25 +0000 (GMT) Received: from dwillispc8 ([166.35.225.166]) by omta1.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000301185216.QDXZ1802@dwillispc8>; Wed, 01 Mar 2000 12:52:16 -0600 Date: Wed, 01 Mar 2000 12:52:09 -0600 From: Dean Willis Subject: RE: Information request! (Billing Package?) In-reply-to: <38BD2E56.5662E965@inet.com> To: Nathan Nelson , "Rosen, Brian" Cc: sip@lists.research.bell-labs.com Message-id: <000101bf83af$3f565080$a6e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit My sponsors would certainly be interested in a complete and standard CDR format that would be supported by multiple vendors. Is that a SIP WG item? As I understand it this sort of accounting work is in the domain of the AAA (Authentication, Authorization, Accounting) working group. As we're currently using RADIUS to throw most of our CDRs, and RADIUS is in AAA, that's where I've been sending CDR issues. -- Dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Nathan > Nelson > Sent: Wednesday, March 01, 2000 8:51 AM > To: Rosen, Brian > Cc: sip@lists.research.bell-labs.com > Subject: Re: Information request! (Billing Package?) > > > The point that was being ask is not specific to SIP, but more general to a > decomposed architectures. > > The current formats that are used to bill PSTN traffic are based > on AMA BAF or > a carrier/vendor defined CDR. Inet believes there is a need to build a > standard format for a Transaction over IP record that allows for > elements and > parameters to be recorded. > > Some of the key components of this record could be: > > A Tracking field to tie multiple records from multiple > platforms together > Time Stamps > Usage Stamps > Originating Information (PSTN Number, IP address, email address.....) > Terminating Information (PSTN Number, IP address, email address....) > Terminating Port/ Media Gateway > Originating Port/Media Gateway > Amount of bandwidth used > Types of Applications used > Premiums associated with Applications > Application Information (Application server IP addresses) > Intermediate network usage > > One of the basic issues with a decomposed architecture from an accounting > aspect is that multiple devices are involved in call set, > routing, application > usage, signaling, and finally termination. It would be nice to see IETF > support a group that looks at accountability and billing, or at > least provide > a basic model to build such records. > > Thx, > Nate Nelson > Inet > > "Rosen, Brian" wrote: > > > Interesting, I assumed everything EXCEPT a gateway throws CDRs. > > Assuming a decomposed gateway, the GW feeds statistics to a Call Agent > > (which would be a SIP UA among other things) that throws CDRs. > > > > The billing system collates all the CDRs. > > > > The spec required is, of course, the format of the CDR and the way they > > are transported. You could claim that a "transaction log" is a form of > > CDR I suppose. > > > > I'd certainly agree that SIP itself doesn't have any "billing package". > > A UA and a server might, but that is independent of the > protocol. Billing > > might very well impact some things in SIP. > > > > Brian > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@wcom.com] > > > Sent: Tuesday, February 29, 2000 2:41 PM > > > To: Mart Nurmet; sip@lists.research.bell-labs.com > > > Subject: RE: Information request! (Billing Package?) > > > > > > > > > What would a billing package look like? I've never really > > > understood the > > > concept, and it might be useful to talk about it some more. > > > > > > Here's how some implementors are doing it: > > > > > > 1) Gateways throw CDRs using RADIUS or something similar. > > > This feeds into > > > rating, reporting, and billing systems, > > > > > > 2) SIP servers record transaction logs. These may feed into rating and > > > billing systems, and probably feed into reporting systems. > > > > > > 3) QoS PEP and PDPs log resource usages. These feed upstream as well. > > > > > > 4) Other systems, like profile managers, report usage. > > > > > > 5) Rating, reporting, and billing systems sift thru the vast > > > amounts of > > > information coming at them and make useful things happen. > > > > > > All of these things use other protocols and systems -- they aren't SIP > > > specific. They do rely on SIP functions like authentication > > > -- that is, the > > > goal of achieving billing functions has driven some > > > requirements into the > > > design of SIP. However, other than driving some requirements > > > to SIP, such > > > efforts are generally considered to be outside the scope of > > > the SIP WG. > > > > > > Are you perhaps proposing to add functionality to SIP to > > > simplify or enhance > > > reporting capabilities or to simplify the task of driving > > > downstream billing > > > systems? > > > > > > -- > > > Dena > > > > -----Original Message----- > > > > From: owner-sip@lists.research.bell-labs.com > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of > > > Mart Nurmet > > > > Sent: Monday, February 28, 2000 2:24 PM > > > > To: sip@lists.research.bell-labs.com > > > > Subject: Information request! (Billing Package?) > > > > > > > > > > > > I am looking for information if there has been any work > > > done to generate a > > > > billing package for SIP. From my look at the available > > > > information there does > > > > not seem to be any. Is that the case or am I missing something? > > > > > > > > Thank you, > > > > -Mart > > > > > > > > > > > > > > > > From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 17:05:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14387 for ; Wed, 1 Mar 2000 17:05:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 690EB52E4; Wed, 1 Mar 2000 17:03:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D8AC552E5; Wed, 1 Mar 2000 17:03:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A7A3152E4 for ; Wed, 1 Mar 2000 17:03:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 17:01:11 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Wed Mar 1 16:58:40 EST 2000 Received: from cisco.com (localhost [127.0.0.1]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id RAA05531 for ; Wed, 1 Mar 2000 17:01:09 -0500 (EST) Message-ID: <38BD9325.704123CA@cisco.com> Date: Wed, 01 Mar 2000 17:01:09 -0500 From: Sudipto Mukherjee Organization: Cisco X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Tag in 200 OK response for CANCEL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I need a clarification about adding of tag in the To header of 200 OK response for CANCEL and BYE - A UAS receives a CANCEL request for a pending INVITE transaction. If the "To" header in the INVITE and the subsequent CANCEL did *not* have a tag in the To header, does the UAS add a tag in the "To" header of the 200 OK response for the CANCEL? Sec 6.38 To, of the SIP specs says - The "tag" must be added for all definitive responses for all methods and MAY be added for informational responses for a UAS or RS." Also, does a UAC receiving a BYE (Called Party Release) need to add a tag in the "To" header of the 200 OK response ? The From header in BYE has a tag but there is *no* tag in the To header. Thanks - Sudipto From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 18:23:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16345 for ; Wed, 1 Mar 2000 18:23:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C826A52DC; Wed, 1 Mar 2000 18:21:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4656452DF; Wed, 1 Mar 2000 18:21:25 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BCA2452DC for ; Wed, 1 Mar 2000 18:21:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 18:20:15 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 1 18:17:43 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA13456; Wed, 1 Mar 2000 18:20:17 -0500 (EST) Message-ID: <38BDA6DD.52DF808A@dynamicsoft.com> Date: Wed, 01 Mar 2000 18:25:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Benny Prijono Cc: "sip@lists.research.bell-labs.com" Subject: Re: Loop detection in Invite request in stateless proxy References: <38BBF521.C450DD9F@theseventhson.freeserve.co.uk> <38BCB3FE.1E0803C1@dynamicsoft.com> <38BD1EC0.54E50471@theseventhson.freeserve.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Benny Prijono wrote: > > Jonathan Rosenberg wrote: > > > -deleted. > > > > > Remember, stateful/stateless proxies are logic entities, and which role > > a real device takes can differ from request to request. > > > > Ah, that's it! > Seems that although I've re-read the RFC at least 2-3 times, still I > missed this concept, badly.. ;) Its probably not easy to figure out from the spec. I've made a note to clarify in the next version. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 19:17:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18592 for ; Wed, 1 Mar 2000 19:17:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EC8DB52C8; Wed, 1 Mar 2000 19:15:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 60E8352D4; Wed, 1 Mar 2000 19:15:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D1F6052C8 for ; Wed, 1 Mar 2000 19:15:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 19:14:16 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Wed Mar 1 19:11:45 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id TAA19173; Wed, 1 Mar 2000 19:14:14 -0500 (EST) Message-ID: <38BDB256.5470ED3B@cisco.com> Date: Wed, 01 Mar 2000 19:14:14 -0500 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Stateful/Stateless proxies Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit As per the FAQ on Henning's page - a stateless proxy cannot fork. However it will still try to find out the next hop based on some location service . So, what should the stateless proxy do if the location service returns more than one contact point - * Send request to only one * Send to all Thanks, Shail From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 22:39:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22895 for ; Wed, 1 Mar 2000 22:39:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 18D6252AB; Wed, 1 Mar 2000 22:37:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8C16852C4; Wed, 1 Mar 2000 22:37:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 6594B52AB for ; Wed, 1 Mar 2000 22:37:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 1 22:36:55 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 1 22:34:22 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id JAA20346; Thu, 2 Mar 2000 09:33:54 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256896.0013F21D ; Thu, 2 Mar 2000 09:07:51 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Message-ID: <65256896.0013F1E5.00@sampark.hss.hns.com> Date: Thu, 2 Mar 2000 09:07:50 +0530 Subject: Re: Stateful/Stateless proxies Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Well, we could try each one in sequence , till success, as another option ? I dont think the RFC states an action explicitly - this being seemingly an implementation issue. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Shail Bhatnagar on 03/02/2000 05:44:14 AM To: sip@lists.research.bell-labs.com cc: Subject: Stateful/Stateless proxies As per the FAQ on Henning's page - a stateless proxy cannot fork. However it will still try to find out the next hop based on some location service . So, what should the stateless proxy do if the location service returns more than one contact point - * Send request to only one * Send to all Thanks, Shail From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 1 23:19:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23341 for ; Wed, 1 Mar 2000 23:19:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5D94D52C4; Wed, 1 Mar 2000 23:17:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 26D3E52C8; Wed, 1 Mar 2000 23:17:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F3E1B52C4 for ; Wed, 1 Mar 2000 23:17:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 1 23:16:08 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 1 23:13:36 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA24427; Thu, 2 Mar 2000 10:12:54 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256896.00178266 ; Thu, 2 Mar 2000 09:46:47 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Sudipto Mukherjee Cc: sip@lists.research.bell-labs.com Message-ID: <65256896.00178171.00@sampark.hss.hns.com> Date: Thu, 2 Mar 2000 09:46:43 +0530 Subject: Re: Tag in 200 OK response for CANCEL Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk sm> A UAS receives a CANCEL request for a pending INVITE transaction. sm> If the "To" header in the INVITE and the subsequent CANCEL did sm> *not* have a tag in the To header, does the UAS add a tag in sm> the "To" header of the 200 OK response for the CANCEL? Yes, I think it should as this CANCEL might have been forked some where in between.Also, this would serve as a match mechanism for the UAS for future forked requests it received. sm> Sec 6.38 To, of the SIP specs says - sm> The "tag" must be added for all definitive responses for all methods sm> and MAY be added for informational responses for a UAS or RS." sm> Also, does a UAC receiving a BYE (Called Party Release) need to add sm> a tag in the "To" header of the 200 OK response ? The From header sm> in BYE has a tag but there is *no* tag in the To header. Yes, again I think it should. A "tag" in the From field is used if multiple callers use the same From address. This has nothing to do with forking of messages by proxies as such. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 00:29:37 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24566 for ; Thu, 2 Mar 2000 00:29:35 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 66F4A52B6; Thu, 2 Mar 2000 00:24:10 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B6BF352D4; Thu, 2 Mar 2000 00:24:09 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id D355D52B6 for ; Thu, 2 Mar 2000 00:23:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 2 00:23:00 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Mar 2 00:20:29 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust15.tnt2.long-branch.nj.da.uu.net [63.25.226.15]) id QQiesr03438; Thu, 2 Mar 2000 05:19:30 GMT Message-ID: <38BDFA3E.29193BFA@dynamicsoft.com> Date: Thu, 02 Mar 2000 00:21:02 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Subject: Re: Stateful/Stateless proxies References: <38BDB256.5470ED3B@cisco.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit As was noted several times on this list, stateful or stateless are logical entities, not physical proxy servers. A single physical proxy may act as stateless in some situations and as stateful in others. To answer your question, the proxy has several options in the case you describe: it can act stateful, it can choose the location with the highest q value, a random location, etc. Note that a proxy cannot fork, do sequential search on contacts or return a redirect response if it wants to remain stateless. --- Igor Slepchin Shail Bhatnagar wrote: > > As per the FAQ on Henning's page - a stateless proxy cannot fork. However it > will still try to find out the next hop based on some location service . So, > what should the stateless proxy do if the location service returns more than > one contact point - > * Send request to only one > * Send to all > > Thanks, > Shail From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 00:37:21 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24723 for ; Thu, 2 Mar 2000 00:37:21 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6DD7752D5; Thu, 2 Mar 2000 00:32:11 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AD6F652D4; Thu, 2 Mar 2000 00:32:10 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 44C5A52D5 for ; Thu, 2 Mar 2000 00:31:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 2 00:29:59 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Mar 2 00:27:27 EST 2000 Received: from dynamicsoft.com (1Cust248.tnt1.freehold.nj.da.uu.net [63.17.113.248]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA13671; Thu, 2 Mar 2000 00:29:50 -0500 (EST) Message-ID: <38BDFD7E.B477496D@dynamicsoft.com> Date: Thu, 02 Mar 2000 00:34:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: Sudipto Mukherjee , sip@lists.research.bell-labs.com Subject: Re: Tag in 200 OK response for CANCEL References: <65256896.00178171.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit archow@hss.hns.com wrote: > > sm> A UAS receives a CANCEL request for a pending INVITE transaction. > sm> If the "To" header in the INVITE and the subsequent CANCEL did > sm> *not* have a tag in the To header, does the UAS add a tag in > sm> the "To" header of the 200 OK response for the CANCEL? > > Yes, I think it should as this CANCEL might have been forked some where in > between.Also, this would serve as a match mechanism for the UAS for future > forked requests it received. No, I disagree. Tags are for the purpose of allowing the UAC to disambiguate responses to a forked request. CANCEL is unlike other requests in that its responses are absorbed at each hop. Thus, even if the UAS inserted a tag into the 200 OK to CANCEL, this tag would never be seen by any entity besides the previous hop - probably a proxy. Note also that a UAC will never receive more than a single 200 OK to a CANCEL, so the tag for disambiguation is useless. > > sm> Sec 6.38 To, of the SIP specs says - > sm> The "tag" must be added for all definitive responses for all methods > sm> and MAY be added for informational responses for a UAS or RS." > > sm> Also, does a UAC receiving a BYE (Called Party Release) need to add > sm> a tag in the "To" header of the 200 OK response ? The From header > sm> in BYE has a tag but there is *no* tag in the To header. > > Yes, again I think it should. A "tag" in the From field is used if multiple > callers use the same From address. This has nothing to do with forking of > messages by proxies as such. I disagree here as well. The local and remote addresses (obtained from the To and From fields, including the tags) that identify the call leg are established upon call setup, and remain fixed for the duration of the call leg. Adding a tag in a subsequent request (BYE or re-INVITE) is going to alter this identifier and likely cause one side or the other to not be able to match requests or responses to a particular call leg. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 00:42:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24770 for ; Thu, 2 Mar 2000 00:42:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 42A4552C8; Thu, 2 Mar 2000 00:38:42 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0A89F52D6; Thu, 2 Mar 2000 00:38:40 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id CD7B852C8 for ; Thu, 2 Mar 2000 00:37:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 2 00:36:09 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Mar 2 00:33:37 EST 2000 Received: from dynamicsoft.com (1Cust248.tnt1.freehold.nj.da.uu.net [63.17.113.248]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA13676; Thu, 2 Mar 2000 00:34:03 -0500 (EST) Message-ID: <38BDFE7C.620F297A@dynamicsoft.com> Date: Thu, 02 Mar 2000 00:39:08 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: Shail Bhatnagar , sip@lists.research.bell-labs.com Subject: Re: Stateful/Stateless proxies References: <65256896.0013F1E5.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit A proxy can do sequential search as you suggest, but it also must be stateful to do so (it needs to know that when a non-200 OK comes in response to the first request, it must try the next one. This requires state). So, doing sequential solves nothing. Remember, a stateless proxy is a logical role. An actual server "box" can and will assume differing logical roles on a call by call basis. If the location service returns multiple Contacts, the server can be stateful for this transaction. An alternative which enables stateless operation is to proxy to only the contact with the highest q value, and none of the others. -Jonathan R. archow@hss.hns.com wrote: > > Well, we could try each one in sequence , till success, as another option ? > I dont think the RFC states an action explicitly - this being seemingly an > implementation issue. > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > Shail Bhatnagar on 03/02/2000 05:44:14 AM > > To: sip@lists.research.bell-labs.com > cc: > > Subject: Stateful/Stateless proxies > > As per the FAQ on Henning's page - a stateless proxy cannot fork. However > it > will still try to find out the next hop based on some location service . > So, > what should the stateless proxy do if the location service returns more > than > one contact point - > * Send request to only one > * Send to all > > Thanks, > Shail -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 00:50:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24839 for ; Thu, 2 Mar 2000 00:50:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 38D8852D6; Thu, 2 Mar 2000 00:46:05 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7CD3252DA; Thu, 2 Mar 2000 00:46:04 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 27D7F52D6 for ; Thu, 2 Mar 2000 00:45:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 2 00:43:56 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Thu Mar 2 00:41:23 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA01851; Thu, 2 Mar 2000 11:38:45 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256896.001F0A80 ; Thu, 2 Mar 2000 11:09:03 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Igor Slepchin Cc: Shail Bhatnagar , sip@lists.research.bell-labs.com Message-ID: <65256896.001F09EF.00@sampark.hss.hns.com> Date: Thu, 2 Mar 2000 11:09:01 +0530 Subject: Re: Stateful/Stateless proxies Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Oops yes, you are right. I thought a stateless proxy would maintain intermediate-state (ie transaction state, not complete call state) which is not the case. so you cannot do sequential search as I initally mentioned. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems is> Note that a proxy cannot fork, do sequential search on contacts or return a redirect response is> if it wants to remain stateless. Igor Slepchin on 03/02/2000 10:51:02 AM To: Shail Bhatnagar cc: sip@lists.research.bell-labs.com Subject: Re: Stateful/Stateless proxies As was noted several times on this list, stateful or stateless are logical entities, not physical proxy servers. A single physical proxy may act as stateless in some situations and as stateful in others. To answer your question, the proxy has several options in the case you describe: it can act stateful, it can choose the location with the highest q value, a random location, etc. Note that a proxy cannot fork, do sequential search on contacts or return a redirect response if it wants to remain stateless. --- Igor Slepchin Shail Bhatnagar wrote: > > As per the FAQ on Henning's page - a stateless proxy cannot fork. However it > will still try to find out the next hop based on some location service . So, > what should the stateless proxy do if the location service returns more than > one contact point - > * Send request to only one > * Send to all > > Thanks, > Shail From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 01:17:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25987 for ; Thu, 2 Mar 2000 01:17:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 11EB652DD; Thu, 2 Mar 2000 00:58:35 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AA97B52E3; Thu, 2 Mar 2000 00:58:33 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id E159A52D4 for ; Tue, 29 Feb 2000 10:31:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 1 10:29:21 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Tue Feb 29 10:26:52 EST 2000 Received: from cisco.com (localhost [127.0.0.1]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA13156; Tue, 29 Feb 2000 10:29:19 -0500 (EST) Message-ID: <38BBE5CE.7A9F8EF@cisco.com> Date: Tue, 29 Feb 2000 10:29:18 -0500 From: Michael Pham X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Cc: "manojb@cisco.com" , "sudiptom@cisco.com" Subject: Call Transfer and Requested-By Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Could someone comment on how the Requested-By header should be populated in a blind transfer scenario where Requested-By is included in the Invite request sent to the transferred-to party? It's my understanding that Requested-By should identify the party initiating the transfer so using the From/To header (from the Bye) does not always guarantee the true endpoint requesting the transfer. Would using the Contact header be more appropriate? Regards, Michael From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 01:21:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26328 for ; Thu, 2 Mar 2000 01:21:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A728A52F0; Thu, 2 Mar 2000 01:01:05 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C03E852EC; Thu, 2 Mar 2000 01:00:18 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DBA9C52D4 for ; Tue, 29 Feb 2000 15:29:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 15:28:47 EST 2000 Received: from seattle.3com.com ([129.213.128.97]) by dusty; Tue Feb 29 15:26:18 EST 2000 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA24887 for ; Tue, 29 Feb 2000 12:28:44 -0800 (PST) From: Anoop_Tripathi@3com.com Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id MAA02427 for ; Tue, 29 Feb 2000 12:28:44 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 88256894.00707915 ; Tue, 29 Feb 2000 12:28:30 -0800 X-Lotus-FromDomain: 3COM To: sip@lists.research.bell-labs.com Message-ID: <88256894.007077B8.00@hqoutbound.ops.3com.com> Date: Tue, 29 Feb 2000 14:30:18 -0600 Subject: Why are location servers and redirect servers defined as two separate servers. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, In the RFC 2543, the location server and redirect server are defined as two different servers which could optionally be co-located. My understanding is a redirect server gets an INVITE request and sends a 3XX response (or a failure response ) for the request. a location server gets a location request and sends a location response. Aren't the two the same. So why define a location server in the SIP world and leave the interface undefined instead it would be better if we collapsed them into one. To me the location server seems more like a database behind a redirect server. Could somebody please clarify this. Thanks, Anoop Tripathi 3COM From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 01:26:17 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26678 for ; Thu, 2 Mar 2000 01:26:17 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 50B5D52E8; Thu, 2 Mar 2000 01:03:19 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 303E252EB; Thu, 2 Mar 2000 01:00:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 92CF152C8 for ; Tue, 29 Feb 2000 23:41:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 23:40:54 EST 2000 Received: from web3405.mail.yahoo.com ([204.71.203.59]) by dusty; Tue Feb 29 23:38:25 EST 2000 Message-ID: <20000301044052.25231.qmail@web3405.mail.yahoo.com> Received: from [202.54.89.47] by web3405.mail.yahoo.com; Tue, 29 Feb 2000 20:40:52 PST Date: Tue, 29 Feb 2000 20:40:52 -0800 (PST) From: Steve Little Subject: Call Leg in SIP To: SIP Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, according to SIP, a call leg is defined as an end-end relation b/w UAs and has nothing to do with intermediate servers. Now does that mean that a particular call can have multiple call legs _only_ if some server in between forked and not otherwise ? And also then, the Tag field is the differentiator for call legs within a call-id. Is this true ? One more Q - H.323 (afaik) defines call legs as A-P and P-B where P is the GK and A & B the EPs. Any concrete reason why the call leg of SIP/H.323 differs in definiton ? Thx __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 01:30:46 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26986 for ; Thu, 2 Mar 2000 01:30:46 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 46C7D52EA; Thu, 2 Mar 2000 01:03:27 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0038F52E5; Thu, 2 Mar 2000 01:01:50 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id D4F4252DC for ; Wed, 1 Mar 2000 18:01:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 1 17:59:28 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Wed Mar 1 17:56:56 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQR00G5CM8XB5@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 1 Mar 2000 22:58:15 +0000 (GMT) Received: from omzexch007.mcit.com (OMZEXCH007.mcit.com [166.37.194.38]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id PAA28676; Wed, 01 Mar 2000 15:11:26 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2571.0) id ; Wed, 01 Mar 2000 15:11:13 +0000 Content-return: allowed Date: Wed, 01 Mar 2000 15:11:12 +0000 From: "Rawlins, Diana" Subject: RE: Question on achieveing Assured QoS using SIP/COPS To: "'Bryan Byerly'" , sip@lists.research.bell-labs.com, rap@iphighway.com Message-id: <75C79E507864D3118AFC00805FEAB7D8426E19@ripexch001.mcit.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2571.0) Content-type: text/plain; charset="ISO-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Byran, >>If so, could someone please sketch a brief call flow for me of >>how to achieve assured QoS using the outsourcing model of COPS? For those who want to assure that the QoS is available for the session prior to completion of call setup. Here's a proposed message flow. Soon the new version of http://www.ietf.org/internet-drafts/draft-sinnreich-interdomain- sip-qos-osp-00 will be available with an explanation of assured outsourcing (pull) model as well as descriptions and call flows of other QoS alternatives for sessions. ++++ QoS Assured PULL +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY| |Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | | +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | 1 | | | | | | | | |INVITE | 2 | | | | | | | |------>|REQ OSP 3 | | | | | | |----->| | | | | | | | |------------>| | | | | | | | 4 | | | | | | | | | | | | | | | 5 |<------------| | | | | | | DEC | | 6 | | | | | |<-----| | INVITE | | | 7 | | |---------------------------------------->|INVITE| | | | | | | | |----->| | | | | | | | | 8 | | | | | | | |9 REQ | 183 | | | | | | | |Assure|<-----| | | | | | | |<-----| | | | | | | | |10 DEC| | | | | | 11 183 | |----->| | | |<----------------------------------------| | | |12 REQ| | | | | | | | |Assure| | | | | | | | |----->| | | | | | | | |13 DEC| | | | | | | | |<-----| | | | | | | |14 183 | | | | | | | | |<------| | | | | | | | - continue call setup - Fig.5 QoS Assured pull - call setup - call setup continued - +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY| |Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | | +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | 15 PATH/SBM | | | | | | |====================>| | | | | | | | |16 REQ| | | | | | | | | PATH | | | | | | | | |<-----| | | | | | | | |17 DEC| 18 PATH |19 REQ| | | | | |----->|------------>| PATH | | | | | | | | |----->| | | | | | | | |20 DEC| | | | | | | | |<-----| | | | | | | | | 21 PATH/SBM | | | | | | |===================>| | | | | | | 22 RESV/SBM | | | | | | |<===================| | | | | | |23 REQ| | | | | | | | | RESV | | | | | | | | |----->| | | | | | | | |24 DEC| | | | | | | | |<-----| | | | | | | | |25 RPT| | | | | |27 REQ| 26 RESV |----->| | | | | | RESV |<------------| | | | | | |<-----| | | | | | | | |28 DEC| | | | | | | | |----->| | | | | | | | |29 RPT| | | | | | | | |<-----| | | | | | | 30 RESV/SBM | | | | | | | |<====================| | | | | | | 31 RESV-CONF/SBM |32 RESV-CONF | 33 RESV-CONF/SBM | |====================>|------------>|===================>| - continue call flow - Fig.5a QoS Assured pull - call setup - continue QoS Assured pull call setup (Direction 2) +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | SIP | |SIP| |POL| | R | |CH | | R | |POL| |SIP| |GWY| |Phone| | 1 | | 1 | | 1 | | | | 2 | | 2 | | 2 | | | +-----+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | | | | 34 PATH/SBM | |<====================| | |<===================| | | | | | |35 REQ| | | | | | | | | PATH | | | | | | | | |----->| | | | | |38 REQ| 37 PATH |36 DEC| | | | | | PATH |<------------|<-----| | | | | |<-----| | | | | | | | |39 DEC| | | | | | | | |----->| | | | | | | 40 PATH/SBM | | | | | | | |<====================| | | | | | | 41 RESV/SBM | | | | | | | |====================>| | | | | | | | |42 REQ| | | | | | | | | RESV | | | | | | | | |<-----| | | | | | | | |43 DEC| | | | | | | | |----->| | | | | | | | |44 RPT| | | | | | | | |<-----| 45 RESV | | | | | | | |------------>|46 REQ| | | | | | | | | RESV | | | | | | | | |----->| | | | | | | | |47 DEC| | | | | | | | |<-----| | | | | | | | |48 RPT| | | | | | | | |----->| | | | | | | | | | 49 RESV/SBM | | | | | | |===================>| | 52 RESV-CONF/SBM |51 RESV-CONF | 50 RESV-CONF/SBM | |<====================|<------------|<===================| Figure 5.b QoS Assured pull - completing the call setup Regards, Diana Rawlins -----Original Message----- From: Bryan Byerly [mailto:byerly@cisco.com] Sent: Friday, February 25, 2000 9:38 AM To: sip@lists.research.bell-labs.com; rap@iphighway.com Cc: byerly@cisco.com Subject: Question on achieveing Assured QoS using SIP/COPS Hi guys, Assuming a goal of achieving "assured QoS" using generic SIP: (In assured QoS, the phone doesn't ring until resource allocation has been confirmed vs. enabled QoS, when the phone rings and can be answered before QoS is established. In fact, if resources are not available, the enabled QoS conversation would continue (without QoS)). I understand that assured QoS can be achieved using the provisioned (push) model of COPS. (REQ, ... DEC, RPT, ... DEC, RTP, ... DEC, RPT ...) Some examples of proposed provisioned models (push model) which (can) achieve assured QoS are: a) DQoS (using Gate objects) b) COPS-PR (using ASN.1 encoded objects), ... which ones am I leaving out? However, I have not seen assured QoS achieved using the outsourcing model (pull model) of COPS. (REQ, DEC, RPT, .... REQ, DEC, RPT, ... REQ, DEC, RPT, ...) Is it even possible to achieve assured QoS using the outsourcing model (pull model) of COPS? If so, could someone please sketch a brief call flow for me of how to achieve assured QoS using the outsourcing model of COPS? Thanks for your help! Bryan Bryan J. Byerly byerly@cisco.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 01:34:46 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27292 for ; Thu, 2 Mar 2000 01:34:46 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0083652DB; Thu, 2 Mar 2000 01:04:49 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 22BA852DF; Thu, 2 Mar 2000 01:04:43 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1D7A552DB for ; Thu, 2 Mar 2000 01:03:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 01:02:39 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Mar 2 01:00:08 EST 2000 Received: from dynamicsoft.com (1Cust248.tnt1.freehold.nj.da.uu.net [63.17.113.248]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13716; Thu, 2 Mar 2000 01:02:44 -0500 (EST) Message-ID: <38BE0534.C0550868@dynamicsoft.com> Date: Thu, 02 Mar 2000 01:07:48 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Manoj Bhatia Cc: Bryan Byerly , sip@lists.research.bell-labs.com, rap@iphighway.com, herzog@iphighway.com, Burcak_Beser@3com.com Subject: Re: SIP/RSVP: How should the 183 be used? References: <38BC6866.DA4BD32C@cisco.com> <38BCBF88.FAD553DA@dynamicsoft.com> <38BD3D9A.574C12D2@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Manoj Bhatia wrote: > > > Jonathan > > Your comment about 183 clearly says > "according to draft-ietf-sip-183, has no meaning beyond "your > session is proceeding". > > However, we do have provisions for QoS and Security as Session Headers > > for 183. In fact the drafts says that header value of QoS can be used > to establish QoS > relationship between caller and callee. > > How does all that fit into the question Bryan raised ? 183 by itself has no meaning beyond "your session is proceeding", as I suggested. Inclusion of the Session: header with a value of "qos" implies that the UAS wishes to couple resource reservation and call signaling. This does not imply that the UAS has completed resource reservation. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 01:41:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27659 for ; Thu, 2 Mar 2000 01:41:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id F294952D4; Thu, 2 Mar 2000 01:39:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5B1F052DF; Thu, 2 Mar 2000 01:39:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 76EC952D4 for ; Thu, 2 Mar 2000 01:39:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 01:38:22 EST 2000 Received: from mail.mera.ru ([195.98.50.58]) by dusty; Thu Mar 2 01:35:50 EST 2000 Received: from mcseem.mera.ru (mcseem.mera.ru [195.98.57.12]) by mail.mera.ru (8.9.3/8.9.3) with ESMTP id JAA88859; Thu, 2 Mar 2000 09:38:18 +0300 (MSK) Date: Thu, 2 Mar 2000 09:39:40 +0300 From: "Stanislav S. Timinsky" X-Mailer: The Bat! (v1.36) S/N F29DEE5D / Educational Reply-To: "Stanislav S. Timinsky" Organization: MERA Labs. X-Priority: 3 (Normal) Message-ID: <1402.000302@mera.ru> To: sip@lists.research.bell-labs.com Cc: prj.men.sip@mera.ru Subject: Bugs in RFC-2327 (SDP) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Greetings to all! I have decided to report about bugs (in my humble opinion ) in the grammar description of SDP (RFC-2327). I used RFC-2327, which has been issued at April 1998. 1. zone-adjustments = time space ["-"] typed-time *(space time space ["-"] typed-time) *must be* zone-adjustments = "z=" time space ["-"] typed-time *(space time space ["-"] typed-time) 2. key-data = email-safe | "~" | " ^ |------- here *and* safe = alpha-numeric | "'" | "'" | "-" | "." | "/" | ":" | "?" | """ | "#" | "$" | "&" | "*" | ";" | "=" | "@" | "[" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "+" | "~" | " ^ |---- and here *What means a quote at the end of grammar sentences?* 3. proto = 1*(alpha-numeric) ;typically "RTP/AVP" or "udp" for IP4 *If -proto- can has a '/' then -proto- is not alpha-numeric. Maybe it is -1*safe-* 4. multicast-address = 3*(decimal-uchar ".") decimal-uchar "/" ttl [ "/" integer ] ;multicast addresses may be in the range ;224.0.0.0 to 239.255.255.255 *must be* multicast-address = 3*3(decimal-uchar ".") decimal-uchar "/" ttl [ "/" integer ] 5. time = POS-DIGIT 9*(DIGIT) ;sufficient for 2 more centuries *maybe* time = POS-DIGIT 9*9(DIGIT) 6. username = safe ;pretty wide definition, but doesn't include space *must be* username = *safe *or* username = 1*safe 7. decimal-uchar = DIGIT | POS-DIGIT DIGIT | ("1" 2*(DIGIT)) | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT) | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5")) *must be* decimal-uchar = DIGIT | POS-DIGIT DIGIT | ("1" 2*2(DIGIT)) | ("2" ("0"|"1"|"2"|"3"|"4") DIGIT) | ("2" "5" ("0"|"1"|"2"|"3"|"4"|"5")) 8. email-safe = safe | space | tab *must be* email-safe = *(safe | space | tab) -- Best regards, Stanislav S. Timinsky mailto:timinsky@mera.ru Mera Labs. From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 02:03:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04206 for ; Thu, 2 Mar 2000 02:03:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5803552DF; Thu, 2 Mar 2000 02:01:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CA8A952E0; Thu, 2 Mar 2000 02:01:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D5E7352DF for ; Thu, 2 Mar 2000 02:01:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 01:59:10 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Mar 2 01:56:39 EST 2000 Received: from dynamicsoft.com (1Cust248.tnt1.freehold.nj.da.uu.net [63.17.113.248]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13757; Thu, 2 Mar 2000 01:59:17 -0500 (EST) Message-ID: <38BE1275.43327507@dynamicsoft.com> Date: Thu, 02 Mar 2000 02:04:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anoop_Tripathi@3com.com Cc: sip@lists.research.bell-labs.com Subject: Re: Why are location servers and redirect servers defined as twoseparate servers. References: <88256894.007077B8.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anoop_Tripathi@3com.com wrote: > > Hi, > > In the RFC 2543, the location server and redirect server are defined as two > different servers which could optionally be co-located. > My understanding is > a redirect server gets an INVITE request and sends a 3XX response (or a > failure response ) for the request. > a location server gets a location request and sends a location response. One is a SIP entity. The other is the back end database/logic to that SIP entity. Like stateless proxy and registrar, location server is a LOGICAL entity, which may or may not exist as a separate component or even be a component at all. A redirect server may have an in memory database of locations for a user, in which case this memory database is the location server. A proxy may use finger to find a user, in which case finger is the location server. A proxy might have an LDAP interface to a corporate wp database, in which case that database is the location server. We can't "collapse" the location server into the redirect or proxy server, because *logically* they are very different entities. In physical realization, of course they can be collapsed if thats what you want. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 03:19:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08581 for ; Thu, 2 Mar 2000 03:19:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8F83E52D5; Thu, 2 Mar 2000 03:17:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1072E52E0; Thu, 2 Mar 2000 03:17:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5236652D5 for ; Thu, 2 Mar 2000 03:17:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 03:15:41 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Mar 2 03:13:09 EST 2000 Received: from dynamicsoft.com (1Cust248.tnt1.freehold.nj.da.uu.net [63.17.113.248]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA13804; Thu, 2 Mar 2000 02:55:02 -0500 (EST) Message-ID: <38BE1F85.4FBB5619@dynamicsoft.com> Date: Thu, 02 Mar 2000 03:00:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Little Cc: SIP Mailing List Subject: Re: Call Leg in SIP References: <20000301044052.25231.qmail@web3405.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Steve Little wrote: > > Hi, according to SIP, a call leg is defined as an > end-end relation b/w UAs and has nothing to do with > intermediate servers. > > Now does that mean that a particular call can have > multiple call legs _only_ if some server in between > forked and not otherwise ? For the base spec, yes. Call control allows call legs to be explicitly added. > > And also then, the Tag field is the differentiator for > call legs within a call-id. Is this true ? Call leg is defined as local+remote participants plus Call-ID. The tag is part of the local and remote participant. > > One more Q - H.323 (afaik) defines call legs as > > A-P and P-B where P is the GK and A & B the EPs. > > Any concrete reason why the call leg of SIP/H.323 > differs in definiton ? They were developed independently. Call leg also has a different meaning still in traditional circuit telephony. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 04:03:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08936 for ; Thu, 2 Mar 2000 04:03:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6DC7652DE; Thu, 2 Mar 2000 04:01:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D2B3952E1; Thu, 2 Mar 2000 04:01:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F09B452DE for ; Thu, 2 Mar 2000 04:01:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 04:00:05 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Thu Mar 2 03:57:32 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id OAA14125; Thu, 2 Mar 2000 14:55:36 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256896.003119C8 ; Thu, 2 Mar 2000 14:26:18 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: archow@hss.hns.com, Sudipto Mukherjee , sip@lists.research.bell-labs.com Message-ID: <65256896.00311863.00@sampark.hss.hns.com> Date: Thu, 2 Mar 2000 14:26:14 +0530 Subject: Re: Tag in 200 OK response for CANCEL Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, Im a little confused here. my understaning was that a UA receiving a message with more than one Via or a mcast address in it MUST add a tag. Even if say, A sent an INVITE to B thru some proxy P which forked, B now gets the INVITE and puts a tag in its 200 OK since there are now 2 Vias. A gets the 200 OK with the tag that B inserted. however A did not know of the Tag when it sent it . However, this tagged response is the matching response for a request which A sent which was not tagged by itself. So isnt this scenario same as the case for subsequent requests with messages sent without a tag ? Now are we saying that the above specification of inserting tags by UAs holds true only for the first transaction of a call leg and not any more ? Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems > sm> Also, does a UAC receiving a BYE (Called Party Release) need to add > sm> a tag in the "To" header of the 200 OK response ? The From header > sm> in BYE has a tag but there is *no* tag in the To header. > > Yes, again I think it should. A "tag" in the From field is used if multiple > callers use the same From address. This has nothing to do with forking of > messages by proxies as such. jr> I disagree here as well. The local and remote addresses (obtained from jr> the To and From fields, including the tags) that identify the call leg jr> are established upon call setup, and remain fixed for the duration of jr> the call leg. Adding a tag in a subsequent request (BYE or re-INVITE) is jr> going to alter this identifier and likely cause one side or the other to jr> not be able to match requests or responses to a particular call leg. From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 09:20:20 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13430 for ; Thu, 2 Mar 2000 09:20:20 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 80F0852C8; Thu, 2 Mar 2000 09:17:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EB85552D4; Thu, 2 Mar 2000 09:17:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 66CD752C8 for ; Thu, 2 Mar 2000 09:17:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 09:16:44 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Mar 2 09:14:12 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA04258; Thu, 2 Mar 2000 09:16:36 -0500 (EST) Message-ID: <38BE77C2.74F6626A@cs.columbia.edu> Date: Thu, 02 Mar 2000 09:16:34 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: sip@lists.research.bell-labs.com Subject: Re: Stateful/Stateless proxies References: <65256896.001F09EF.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit archow@hss.hns.com wrote: > > Oops yes, you are right. > I thought a stateless proxy would maintain intermediate-state (ie > transaction state, not complete call state) which is not the case. > so you cannot do sequential search as I initally mentioned. > For those new to SIP and the list, it might be helpful to consult the SIP FAQ first (see http://www.cs.columbia.edu/sip). This particular question is summarized there, as is the discussion on billing we just had. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 11:46:29 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17838 for ; Thu, 2 Mar 2000 11:46:29 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E408752C4; Thu, 2 Mar 2000 11:43:35 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 649FD52AB; Thu, 2 Mar 2000 11:43:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4830252C4 for ; Thu, 2 Mar 2000 11:43:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 11:42:52 EST 2000 Received: from qhars001.nortel.com ([192.100.101.18]) by dusty; Thu Mar 2 11:40:20 EST 2000 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars001.nortel.com; Thu, 2 Mar 2000 16:41:35 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Mar 2000 16:41:32 -0000 Message-ID: <33E324D95F44D311AA3E00204840075B550303@zhard00e.europe.nortel.com> From: "Mark Gibson" To: sip@lists.research.bell-labs.com Subject: RE: Cross-domain QoS setup Date: Thu, 2 Mar 2000 16:41:21 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8466.28CD278C" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF8466.28CD278C Content-Type: text/plain Please excuse my ignorance but I cannot find a reference to the PRACK Method listed below in any SIP drafts. Although I have an understanding of its functionality from the example below, I'd like to be sure what it does. Can someone point me towards the relevant document. Cheers Mark -----Original Message----- From: Adam B. Roach [SMTP:Adam.Roach@Ericsson.com] Sent: Tuesday, February 22, 2000 4:11 PM To: jdrosen@dynamicsoft.com; hgs@cs.columbia.edu; Steven.R.Donovan@wcom.com Cc: sip@lists.research.bell-labs.com Subject: Cross-domain QoS setup 3) The PRACK confirming the 18x will echo back the finally agreed-on preconditions. This will serve as a "go ahead" message to the called party to begin its actual resource reservation. -------------------- UAS->UAC SIP/2.0 183 Preconditions To: Adam Roach From: John Q. Public CSeq: 1 INVITE Session: QoS Content-Type: application/sdp v=0 m=audio 48327 RTP/AVP 0 a=qos:mandatory sendrecv m=video 10275 RTP/AVP 31 a=qos:optional sendrecv -------------------- UAC->UAS PRACK sip:adam.roach@ericsson.com SIP/2.0 To: Adam Roach From: John Q. Public CSeq: 2 PRACK Session: QoS Content-Type: application/sdp v=0 m=audio 48327 RTP/AVP 0 a=qos:mandatory sendrecv m=video 10275 RTP/AVP 31 a=qos:optional sendrecv -------------------- ------_=_NextPart_001_01BF8466.28CD278C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Cross-domain QoS setup

Please excuse my ignorance but I = cannot find a reference to the PRACK Method listed below in any SIP = drafts. Although I have an understanding of its functionality from the = example below, I'd like to be sure what it does. Can someone point me = towards the relevant document.

Cheers

Mark

    -----Original = Message-----
    From:   Adam B. Roach = [SMTP:Adam.Roach@Ericsson.com]
    Sent:   Tuesday, February 22, 2000 4:11 PM
    To:     jdrosen@dynamicsoft.com; hgs@cs.columbia.edu; = Steven.R.Donovan@wcom.com
    Cc:     sip@lists.research.bell-labs.com
    Subject:       = Cross-domain QoS setup

    <snip>

    3) The PRACK confirming the 18x will = echo back the finally
       agreed-on preconditions. = This will serve as a "go ahead"
       message to the called = party to begin its actual resource
       reservation.
    <snip>
    --------------------
    UAS->UAC

    SIP/2.0 183 Preconditions
    To: Adam Roach = <adam.roach@ericsson.com>
    From: John Q. Public = <jpublic@ietf.org>
    CSeq: 1 INVITE
    Session: QoS
    Content-Type: application/sdp

    v=3D0
    m=3Daudio 48327 RTP/AVP 0
    a=3Dqos:mandatory sendrecv
    m=3Dvideo 10275 RTP/AVP 31
    a=3Dqos:optional sendrecv
    --------------------
    UAC->UAS

    PRACK sip:adam.roach@ericsson.com = SIP/2.0
    To: Adam Roach = <adam.roach@ericsson.com>
    From: John Q. Public = <jpublic@ietf.org>
    CSeq: 2 PRACK
    Session: QoS
    Content-Type: application/sdp

    v=3D0
    m=3Daudio 48327 RTP/AVP 0
    a=3Dqos:mandatory sendrecv
    m=3Dvideo 10275 RTP/AVP 31
    a=3Dqos:optional sendrecv
    --------------------

------_=_NextPart_001_01BF8466.28CD278C-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 11:54:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18128 for ; Thu, 2 Mar 2000 11:54:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1762352D4; Thu, 2 Mar 2000 11:51:28 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A71FF52AB; Thu, 2 Mar 2000 11:51:26 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id ACE5652AB for ; Thu, 2 Mar 2000 11:51:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 11:49:47 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Thu Mar 2 11:47:16 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQS009KOZF6SR@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 2 Mar 2000 16:35:31 +0000 (GMT) Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id QAA01512; Thu, 02 Mar 2000 16:35:28 +0000 (GMT) Received: from dwillispc8 ([166.35.148.173]) by omta4.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000302163702.LRNB18013@dwillispc8>; Thu, 02 Mar 2000 16:37:02 +0000 Date: Thu, 02 Mar 2000 10:34:00 -0600 From: Dean Willis Subject: RE: Stateful/Stateless proxies In-reply-to: <38BDFE7C.620F297A@dynamicsoft.com> To: Jonathan Rosenberg , archow@hss.hns.com Cc: Shail Bhatnagar , sip@lists.research.bell-labs.com Message-id: <000d01bf8465$1d020c20$ad9423a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The confusion factor is in the semantics of the language. There are what I think os as "Call stateful", "transaction stateful", and "stateless" proxies. My hunch is that most business-useful proxies will end up being fundamentally transaction stateful, with occasional transition to call-stateful for things like parallel or sequential multiple contact resolution. This "change of statefulness" occurs dynamically as part of the processing logic in the proxy. -- Dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Jonathan > Rosenberg > Sent: Wednesday, March 01, 2000 11:39 PM > To: archow@hss.hns.com > Cc: Shail Bhatnagar; sip@lists.research.bell-labs.com > Subject: Re: Stateful/Stateless proxies > > > A proxy can do sequential search as you suggest, but it also must be > stateful to do so (it needs to know that when a non-200 OK comes in > response to the first request, it must try the next one. This requires > state). So, doing sequential solves nothing. Remember, a stateless proxy > is a logical role. An actual server "box" can and will assume differing > logical roles on a call by call basis. If the location service returns > multiple Contacts, the server can be stateful for this transaction. An > alternative which enables stateless operation is to proxy to only the > contact with the highest q value, and none of the others. > > -Jonathan R. > > archow@hss.hns.com wrote: > > > > Well, we could try each one in sequence , till success, as > another option ? > > I dont think the RFC states an action explicitly - this being > seemingly an > > implementation issue. > > > > Regds > > Arjun > > > > -- > > Arjun Roychowdhury @ Hughes Software Systems > > > > Shail Bhatnagar on 03/02/2000 05:44:14 AM > > > > To: sip@lists.research.bell-labs.com > > cc: > > > > Subject: Stateful/Stateless proxies > > > > As per the FAQ on Henning's page - a stateless proxy cannot > fork. However > > it > > will still try to find out the next hop based on some location service . > > So, > > what should the stateless proxy do if the location service returns more > > than > > one contact point - > > * Send request to only one > > * Send to all > > > > Thanks, > > Shail > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 12:19:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19229 for ; Thu, 2 Mar 2000 12:19:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 94D8C52AB; Thu, 2 Mar 2000 12:17:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 154D652D6; Thu, 2 Mar 2000 12:17:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4C18C52AB for ; Thu, 2 Mar 2000 12:17:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 12:15:42 EST 2000 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by dusty; Thu Mar 2 12:13:09 EST 2000 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 2 Mar 2000 17:15:26 +0000 To: Henning Schulzrinne Cc: sip@lists.research.bell-labs.com, Terri Cali Subject: Re: SIP bakeoff registration now open In-reply-to: Your message of "Wed, 01 Mar 2000 13:42:25 EST." <38BD6491.5BA1E6A0@cs.columbia.edu> Date: Thu, 02 Mar 2000 17:15:25 +0000 Message-ID: <5215.952017325@cs.ucl.ac.uk> From: Colin Perkins Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --> Henning Schulzrinne writes: >http://www.sipbakeoff.org/4/ has details. Please contact Terri Cali >(cc'ed) with any questions. > >I look forward to seeing many of you at the bake-off. > >I'd also appreciate feedback on whether and to what extent we should >test more formally for RTP interoperability at this event. This has >become an issue as we cannot progress RTP to draft status without more >implementations that comply. Since a phone that only rings but doesn't >"talk" is of somewhat limited use, this might be of some interest. (This >would obviously only affect UAs, not servers.) I'd strongly support moves to perform RTP interoperability testing at the SIP bakeoff. The AVT working group has produced a number of internet drafts listing those features which would need to be tested and suggesting testing procedures: draft-ietf-avt-rtp-interop-02.txt draft-ietf-avt-profile-interop-00.txt draft-ietf-avt-rtptest-02.txt And as Henning says, this demonstration must be completed before the revised RTP specification can become an RFC. I would also encourage vendors who have performed in-house interoperability testing of RTP implementations to consider making this information available to the AVT working group chairs, so we can complete the interoperability requirements (we're aware that some vendors have concerns with making this available - contact us, and we can work to address them). Colin From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 12:30:29 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19862 for ; Thu, 2 Mar 2000 12:30:29 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4934752D6; Thu, 2 Mar 2000 12:27:31 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AB4D252DB; Thu, 2 Mar 2000 12:27:30 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AFEC752D6 for ; Thu, 2 Mar 2000 12:27:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 12:25:51 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Thu Mar 2 12:23:19 EST 2000 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id LAA28870; Thu, 2 Mar 2000 11:25:48 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA08930; Thu, 2 Mar 2000 11:25:48 -0600 (CST) Received: from b04a19.exu.ericsson.se (b04a19 [138.85.60.119]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA03036; Thu, 2 Mar 2000 11:25:47 -0600 (CST) Received: from exu.ericsson.se (localhost [127.0.0.1]) by b04a19.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA01137; Thu, 2 Mar 2000 11:25:46 -0600 (CST) Message-ID: <38BEA41A.55E64575@exu.ericsson.se> Date: Thu, 02 Mar 2000 11:25:46 -0600 From: Michelle Kitchings Reply-To: Michelle.Kitchings@ericsson.com Organization: Ericsson, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Mark Gibson Cc: sip@lists.research.bell-labs.com Subject: Re: Cross-domain QoS setup References: <33E324D95F44D311AA3E00204840075B550303@zhard00e.europe.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Mark, See http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-00.txt The link is on Hennings's page (http://www.cs.columbia.edu/~hgs/sip), under Drafts -> Extensions -> Reliability of Provisional Responses. -- Michelle Kitchings | Ph: +1 972 583 7101 | 1010 E. Arapaho, MS L-04 Ericsson, Inc. | Fax: +1 972 669 0154 | Richardson, TX 75081 USA > Mark Gibson wrote: > > Please excuse my ignorance but I cannot find a reference to the PRACK Method > listed below in any SIP drafts. Although I have an understanding of its > functionality from the example below, I'd like to be sure what it does. Can > someone point me towards the relevant document. > > Cheers > > Mark ... From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 13:24:40 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21944 for ; Thu, 2 Mar 2000 13:24:37 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1F49652DC; Thu, 2 Mar 2000 13:21:49 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8311252E0; Thu, 2 Mar 2000 13:21:48 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 25C1852DC for ; Thu, 2 Mar 2000 13:21:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 13:20:01 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Thu Mar 2 13:17:30 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA17189; Thu, 2 Mar 2000 13:19:23 -0500 (EST) Message-ID: <38BEB0AB.20C0ED22@cisco.com> Date: Thu, 02 Mar 2000 13:19:23 -0500 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: archow@hss.hns.com, Sudipto Mukherjee , sip@lists.research.bell-labs.com Subject: Re: Tag in 200 OK response for CANCEL References: <65256896.00178171.00@sampark.hss.hns.com> <38BDFD7E.B477496D@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Then the following lines should be deleted/appropriately modified in the spec : "The "tag" is added for all definitive responses for all methods, and MAY be added for informational responses from a UAS or redirect server." Thanks, Shail Jonathan Rosenberg wrote: > > > No, I disagree. Tags are for the purpose of allowing the UAC to > disambiguate responses to a forked request. CANCEL is unlike other > requests in that its responses are absorbed at each hop. Thus, even if > the UAS inserted a tag into the 200 OK to CANCEL, this tag would never > be seen by any entity besides the previous hop - probably a proxy. Note > also that a UAC will never receive more than a single 200 OK to a > CANCEL, so the tag for disambiguation is useless. > > > I disagree here as well. The local and remote addresses (obtained from > the To and From fields, including the tags) that identify the call leg > are established upon call setup, and remain fixed for the duration of > the call leg. Adding a tag in a subsequent request (BYE or re-INVITE) is > going to alter this identifier and likely cause one side or the other to > not be able to match requests or responses to a particular call leg. > > -Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 14:00:12 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22802 for ; Thu, 2 Mar 2000 14:00:11 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A2F6152E0; Thu, 2 Mar 2000 13:57:35 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 22F8852DE; Thu, 2 Mar 2000 13:57:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id DEAD952DB for ; Thu, 2 Mar 2000 13:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 2 13:55:04 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Mar 2 13:52:32 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA27106; Thu, 2 Mar 2000 13:54:35 -0500 (EST) Message-ID: <38BEB8E9.1801C894@cs.columbia.edu> Date: Thu, 02 Mar 2000 13:54:33 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: Jonathan Rosenberg , archow@hss.hns.com, Sudipto Mukherjee , sip@lists.research.bell-labs.com Subject: Re: Tag in 200 OK response for CANCEL References: <65256896.00178171.00@sampark.hss.hns.com> <38BDFD7E.B477496D@dynamicsoft.com> <38BEB0AB.20C0ED22@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit This clearer? A UAS or redirect server {\MUST} add a ``\header{tag}'' parameter for all final responses for all transactions within a call leg. All such parameters have the same value within the same call leg. These servers {\MAY} add the \header{tag} for informational responses during the initial {\INVITE} transaction, but {\MUST} add a tag to informational responses for all subsequent transactions. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 22:16:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04663 for ; Thu, 2 Mar 2000 22:16:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3305E52B6; Thu, 2 Mar 2000 22:13:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A3D7E52DA; Thu, 2 Mar 2000 22:13:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D6DF752B6 for ; Thu, 2 Mar 2000 22:13:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 22:13:04 EST 2000 Received: from mail.huawei.com.cn ([202.96.135.132]) by dusty; Thu Mar 2 22:10:32 EST 2000 Received: from y13638 ([10.108.22.162]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA9463; Fri, 3 Mar 2000 11:13:14 +0800 Message-ID: <000c01bf84be$292e0e00$a2166c0a@y13638.huawei.com.cn> Reply-To: "yinshaohua" From: "yinshaohua" To: "Igor Slepchin" Cc: Subject: Stateful/Stateless proxies Date: Fri, 3 Mar 2000 11:11:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi: Now that " A single physical proxy may act as stateless in some situations and as stateful in others" , what role do we comply with when making a proxy stateful or stateless after receiving a INVITE request? If having a role , there can process a request clearly for Proxy. Am I correct ? Regards! Shaohua Yin 2000/3/3 -----Original Message----- ???: Igor Slepchin ???: Shail Bhatnagar ??: sip@lists.research.bell-labs.com ??: 2000?3?2? 13:31 ??: Re: Stateful/Stateless proxies >As was noted several times on this list, stateful or stateless are >logical entities, not physical proxy servers. A single physical proxy >may act as stateless in some situations and as stateful in others. > >To answer your question, the proxy has several options in the case you >describe: it can act stateful, it can choose the location with the >highest q value, a random location, etc. Note that a proxy cannot fork, >do sequential search on contacts or return a redirect response if it >wants to remain stateless. > >--- >Igor Slepchin > > >Shail Bhatnagar wrote: >> >> As per the FAQ on Henning's page - a stateless proxy cannot fork. However it >> will still try to find out the next hop based on some location service . So, >> what should the stateless proxy do if the location service returns more than >> one contact point - >> * Send request to only one >> * Send to all >> >> Thanks, >> Shail > From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 2 22:57:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05905 for ; Thu, 2 Mar 2000 22:57:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2D3D852D5; Thu, 2 Mar 2000 22:55:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9047552DD; Thu, 2 Mar 2000 22:55:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 66FD852D5 for ; Thu, 2 Mar 2000 22:55:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 2 22:55:03 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Thu Mar 2 22:52:26 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id JAA21961; Fri, 3 Mar 2000 09:42:34 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256897.0014BBC8 ; Fri, 3 Mar 2000 09:16:27 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: schulzrinne@cs.columbia.edu Cc: Jonathan Rosenberg , archow@hss.hns.com, Sudipto Mukherjee , sip@lists.research.bell-labs.com Message-ID: <65256897.0014BB33.00@sampark.hss.hns.com> Date: Fri, 3 Mar 2000 09:16:25 +0530 Subject: Re: Tag in 200 OK response for CANCEL Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, With Henning's clarification of the para,: hgs> A UAS or redirect server {\MUST} add a ``\header{tag}'' parameter for hgs> all final responses for all transactions within a call leg. All such hgs> parameters have the same value within the same call leg. These hgs> servers {\MAY} add the \header{tag} for informational responses during hgs> the initial {\INVITE} transaction, but {\MUST} add a tag to hgs> informational responses for all subsequent transactions. relooking at the initial question which Sudipto asked: > sm> Also, does a UAC receiving a BYE (Called Party Release) need to add > sm> a tag in the "To" header of the 200 OK response ? The From header > sm> in BYE has a tag but there is *no* tag in the To header. Can one conclude that the above case will never happen as before BYE, when the first INVITE reaches the UAS without a tag, it MUST add the tag in its 200 OK. Now this tag MUST be the used in all subsequent transactions, so receiving a second transaction without a tag can never happen, unless the sending side is broken ? And in the case it is broken, ie BYE comes now without a tag (though the UAS had send 200OK for INV with a tag) , the UAS cant match the response since the call -leg does not match. He discards it ? (or does he accept it?) If the above is true, then tag is only needed to be added in the first transaction, isnt it ? Thanks Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems archow@hns.com on 03/02/2000 02:26:14 PM To: Jonathan Rosenberg cc: archow, Sudipto Mukherjee , sip@lists.research.bell-labs.com Subject: Re: Tag in 200 OK response for CANCEL Hi, Im a little confused here. my understaning was that a UA receiving a message with more than one Via or a mcast address in it MUST add a tag. Even if say, A sent an INVITE to B thru some proxy P which forked, B now gets the INVITE and puts a tag in its 200 OK since there are now 2 Vias. A gets the 200 OK with the tag that B inserted. however A did not know of the Tag when it sent it . However, this tagged response is the matching response for a request which A sent which was not tagged by itself. So isnt this scenario same as the case for subsequent requests with messages sent without a tag ? Now are we saying that the above specification of inserting tags by UAs holds true only for the first transaction of a call leg and not any more ? Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems > sm> Also, does a UAC receiving a BYE (Called Party Release) need to add > sm> a tag in the "To" header of the 200 OK response ? The From header > sm> in BYE has a tag but there is *no* tag in the To header. > > Yes, again I think it should. A "tag" in the From field is used if multiple > callers use the same From address. This has nothing to do with forking of > messages by proxies as such. jr> I disagree here as well. The local and remote addresses (obtained from jr> the To and From fields, including the tags) that identify the call leg jr> are established upon call setup, and remain fixed for the duration of jr> the call leg. Adding a tag in a subsequent request (BYE or re-INVITE) is jr> going to alter this identifier and likely cause one side or the other to jr> not be able to match requests or responses to a particular call leg. From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 00:37:12 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07371 for ; Fri, 3 Mar 2000 00:37:12 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A471152DA; Fri, 3 Mar 2000 00:32:13 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6237252DE; Fri, 3 Mar 2000 00:32:11 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id BD6AF52DA for ; Fri, 3 Mar 2000 00:31:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 3 00:29:22 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Mar 3 00:26:50 EST 2000 Received: from dynamicsoft.com (1Cust113.tnt1.freehold.nj.da.uu.net [63.17.113.113]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA15973; Fri, 3 Mar 2000 00:25:26 -0500 (EST) Message-ID: <38BF4DFC.A08D724E@dynamicsoft.com> Date: Fri, 03 Mar 2000 00:30:36 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: Robert.Sparks@wcom.com, "'SIP List' (E-mail)" , "Henning Schulzrinne (E-mail)" Subject: Re: UAC use of tags received in responses References: <003201bf73dd$40e24300$8a9223a6@mcit.com> <38A33790.5A052AC6@dynamicsoft.com> <38B574B5.50448657@hplb.hpl.hp.com> <38B6D9E0.7B7BECB8@dynamicsoft.com> <38BA6697.82450B48@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > Jonathan Rosenberg wrote: > > > > Anders Kristensen wrote: > > > > > > I'm not sure it's a problem, but this can give rise to curious > > > situations when the the non-2xx final response was generated by a UAS. > > > In this case the UAS has inserted a To tag and hence believes the call > > > consists of a single leg, whose UAS identifier (the To of the original > > > request) has a tag. > > > > > > The UAC ACKs the response (ACK includes To tag) and resubmits the > > > request *without* To tag. This basically constitutes initiating a new > > > transaction in a new leg. > > > > > > Now I'm not sure if it's well-specified whether the UAS will associate > > > that new request with the existing leg (which has a To tag). I think > > > this would (or should) be the correct behaviour, as it really is the > > > same leg, but I would imagine that different implementations might > > > differ on this point. The consequence is that the second response (say a > > > 2xx) may be returned with the *original* To tag. > > > > Hmm. I don't think this would happen. If the UAS receives a request and > > sends a non-200 response with a tag, the call leg is over. It doesn't > > know whether it will ever receieve another request, so I imagine it will > > flush the state, and thats it. > > This would be true if it wasn't because the UAS has to keep transaction > state hanging around for retransmissions - for a period of approximately > 30 seconds. This is easily enough time for someone to manually type in a > password and resubmit the request. > > > When the new request arrives, it creates > > a new call leg. The tag in the response will probably be different than > > the previous, or it might be the same. > > > > On the UAC, this basically means it really can't associate a tag with > > the call leg until the 200 OK. Before that, any tags it sees in > > provisionals or non-200s might not be the final tag. > > That might work, although it's a bit awkward. It's basically saying that > the UAC shouldn't represent the initial leg as a real leg. No, it can represent the initial leg as a real leg, and have a tag associated with it that it learned from a provisional. However, if the initial INVITE is rejected, the tag is basically "invalidated". You'll launch a new INVITE (assuming the rejection was something like a 401) without a tag. > > > > > > Maybe it should be clarified whether the UAS should respond to the > > > second request with the old or a new To tag, and whether the UAC is > > > supposed to think of the two requests as belonging to different legs? > > > > I don't think we can impose requirements on maintenance of state at a UA > > after rejecting a new INVITE. > > So you're saying that both behaviours are acceptable: if the UAS knows > of the old leg it may or may not respond with the old tag, and it's up > to the UAC to recognize that the response to the resubmitted request > belongs to the new leg. This seems like a reasonable solution to me, > although it basically modifies the rule that a leg is identified by > Call-ID, From, and To headers. No, I don't think its changing this rule. You can almost think of the new request as being on a new leg (in fact, one could conceivably even use a new Call-ID for that resubmitted request - things will still work just fine). > > It is maybe worth noting that the UAC can address this problem > differently by forcing the reissued request to belong to a different leg > (by using a different From tag) or a different call (by using a > different Call-ID). This denies the UAS (and proxies) the opportunity to > recognize that the second request is related to the first, and so should > be discouraged. A good point. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 00:47:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07516 for ; Fri, 3 Mar 2000 00:47:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6770D52DD; Fri, 3 Mar 2000 00:45:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D703E52DF; Fri, 3 Mar 2000 00:45:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 20C3652DD for ; Fri, 3 Mar 2000 00:45:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 00:43:44 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Fri Mar 3 00:41:13 EST 2000 Received: (from shbhatna@localhost) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id AAA21591; Fri, 3 Mar 2000 00:43:10 -0500 (EST) From: Shail Bhatnagar Message-Id: <200003030543.AAA21591@bounty.cisco.com> Subject: Re: Tag in 200 OK response for CANCEL To: archow@hss.hns.com Date: Fri, 3 Mar 2000 00:43:09 -0500 (EST) Cc: sip@lists.research.bell-labs.com In-Reply-To: <65256897.0014BB33.00@sampark.hss.hns.com> from "archow@hss.hns.com" at Mar 03, 2000 09:16:25 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Arjun, I think Sudipto referred to BYE from called party ( so the To in the BYE request will not have a tag - unless the caller put a tag in the From of the initial INVITE). The bottom line for me from this thread is that a tag MUST be appended to the To header of the final response to an INVITE request. ( unless it is re-INVITE request) It should not be appended for final responses to non-INVITE requests. Henning/Jonathan is that a correct statement ?? Thanks, Shail > > > > Hi, > With Henning's clarification of the para,: > > hgs> A UAS or redirect server {\MUST} add a ``\header{tag}'' parameter for > hgs> all final responses for all transactions within a call leg. All such > hgs> parameters have the same value within the same call leg. These > hgs> servers {\MAY} add the \header{tag} for informational responses during > hgs> the initial {\INVITE} transaction, but {\MUST} add a tag to > hgs> informational responses for all subsequent transactions. > > relooking at the initial question which Sudipto asked: > > > sm> Also, does a UAC receiving a BYE (Called Party Release) need to add > > sm> a tag in the "To" header of the 200 OK response ? The From header > > sm> in BYE has a tag but there is *no* tag in the To header. > > > Can one conclude that the above case will never happen as before BYE, when > the first > INVITE reaches the UAS without a tag, it MUST add the tag in its 200 OK. > Now this tag MUST > be the used in all subsequent transactions, so receiving a second > transaction without a tag > can never happen, unless the sending side is broken ? And in the case it is > broken, ie BYE comes > now without a tag (though the UAS had send 200OK for INV with a tag) , the > UAS cant match the response since the call -leg does not match. He discards > it ? (or does he accept it?) > If the above is true, then tag is only needed to be added in the first > transaction, isnt it ? > > Thanks > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > > > > > > > > > > archow@hns.com on 03/02/2000 02:26:14 PM > > To: Jonathan Rosenberg > cc: archow, Sudipto Mukherjee , > sip@lists.research.bell-labs.com > > Subject: Re: Tag in 200 OK response for CANCEL > > > > > > > Hi, > Im a little confused here. > my understaning was that a UA receiving a message with more than one Via or > a mcast address in it MUST add a tag. > Even if say, A sent an INVITE to B thru some proxy P which forked, B now > gets the INVITE and puts a tag in its 200 OK since there are now 2 Vias. A > gets the 200 OK with the tag that B inserted. however A did not know of the > Tag when it sent it . > However, this tagged response is the matching response for a request which > A sent which was not tagged by itself. > So isnt this scenario same as the case for subsequent requests with > messages sent without a tag ? > > Now are we saying that the above specification of inserting tags by UAs > holds true only for the first transaction of a call leg and not any more ? > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > > > > > sm> Also, does a UAC receiving a BYE (Called Party Release) need to add > > sm> a tag in the "To" header of the 200 OK response ? The From header > > sm> in BYE has a tag but there is *no* tag in the To header. > > > > Yes, again I think it should. A "tag" in the From field is used if > multiple > > callers use the same From address. This has nothing to do with forking of > > messages by proxies as such. > > jr> I disagree here as well. The local and remote addresses (obtained from > jr> the To and From fields, including the tags) that identify the call leg > jr> are established upon call setup, and remain fixed for the duration of > jr> the call leg. Adding a tag in a subsequent request (BYE or re-INVITE) > is > jr> going to alter this identifier and likely cause one side or the other > to > jr> not be able to match requests or responses to a particular call leg. > > > > > > > > > > > From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 00:55:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07594 for ; Fri, 3 Mar 2000 00:55:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DC7A852DF; Fri, 3 Mar 2000 00:53:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2490852E0; Fri, 3 Mar 2000 00:53:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EBD1B52DF for ; Fri, 3 Mar 2000 00:53:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 00:51:50 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Mar 3 00:49:19 EST 2000 Received: from dynamicsoft.com (1Cust113.tnt1.freehold.nj.da.uu.net [63.17.113.113]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA15987; Fri, 3 Mar 2000 00:51:55 -0500 (EST) Message-ID: <38BF5431.7C32BF67@dynamicsoft.com> Date: Fri, 03 Mar 2000 00:57:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Pham Cc: sip@lists.research.bell-labs.com, "manojb@cisco.com" , "sudiptom@cisco.com" Subject: Re: Call Transfer and Requested-By References: <38BBE5CE.7A9F8EF@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Good question. The original thinking is that it would be populated with the From field of the BYE. However, if the original call was forwarded, the From field isn't going to be the actual person doing the transfer. Unfortunately, the multiparty conferencing stuff relies on the From field being what is used in Requested-By. Ignoring that problem for the moment, considering just transfer, Contact isn't the right thing either. The address in Contact is usually a fully qualified hostname, when you want something thats more of a logical identifier. An alternative would be to actually have a Requested-By header in the BYE itself, and the URL in there is copied into the INVITE triggere from the transfer. -Jonathan R. Michael Pham wrote: > > Could someone comment on how the Requested-By header should be populated > in a blind transfer scenario where Requested-By is included in the > Invite request sent to the transferred-to party? It's my understanding > that Requested-By should identify the party initiating the transfer so > using the From/To header (from the Bye) does not always guarantee the > true endpoint requesting the transfer. Would using the Contact header be > more appropriate? > > Regards, > Michael -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 01:23:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09458 for ; Fri, 3 Mar 2000 01:23:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D86E852E0; Fri, 3 Mar 2000 01:21:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 51EE952E1; Fri, 3 Mar 2000 01:21:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5A20052E0 for ; Fri, 3 Mar 2000 01:21:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 01:19:34 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Mar 3 01:17:02 EST 2000 Received: from dynamicsoft.com (1Cust113.tnt1.freehold.nj.da.uu.net [63.17.113.113]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16009; Fri, 3 Mar 2000 01:19:36 -0500 (EST) Message-ID: <38BF5AAE.F016C385@dynamicsoft.com> Date: Fri, 03 Mar 2000 01:24:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: archow@hss.hns.com, sip@lists.research.bell-labs.com Subject: Re: Tag in 200 OK response for CANCEL References: <200003030543.AAA21591@bounty.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > Arjun, I think Sudipto referred to BYE from called party ( so the To > in the BYE request will not have a tag - unless the caller put a tag in > the From of the initial INVITE). Yes, this is exactly the problem. > > The bottom line for me from this thread is that a tag MUST be appended > to the To header of the final response to an INVITE request. ( unless it is > re-INVITE request) > It should not be appended for final responses to non-INVITE requests. > > Henning/Jonathan is that a correct statement ?? Yes, but what it boils down to is: A UAS {\MUST} add a "\header{tag}" parameter to the final response of an initial \INVITE request for a call. It \MAY add the \header{tag} for informational responses during the initial \INVITE transaction. For any requests after the call is established, responses to an \INVITE copy the \header{To} and \header{From} fields, including any tags which may have been present. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 02:07:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19114 for ; Fri, 3 Mar 2000 02:07:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BE34C52DE; Fri, 3 Mar 2000 02:05:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 37ABF52E2; Fri, 3 Mar 2000 02:05:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A6BFC52DE for ; Fri, 3 Mar 2000 02:05:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 02:03:23 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Mar 3 02:00:52 EST 2000 Received: from dynamicsoft.com (1Cust113.tnt1.freehold.nj.da.uu.net [63.17.113.113]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA16093; Fri, 3 Mar 2000 02:03:11 -0500 (EST) Message-ID: <38BF64E5.E058B23B@dynamicsoft.com> Date: Fri, 03 Mar 2000 02:08:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: yinshaohua Cc: Igor Slepchin , sip@lists.research.bell-labs.com Subject: Re: Stateful/Stateless proxies References: <000c01bf84be$292e0e00$a2166c0a@y13638.huawei.com.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit yinshaohua wrote: > > Hi: > Now that " A single physical proxy may act as stateless in some > situations and as stateful in others" , what role do we comply with when > making a proxy stateful or stateless after receiving a INVITE request? Whichever you want, depening on what it is you wish to accomplish. Its based on administrator policy, the service being invoked, or whatever. The only rules are: 1. if you send TCP, you have to be stateful 2. if you send multicast, you have to be stateful 3. if you fork, you have to be stateful -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 10:16:42 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00036 for ; Fri, 3 Mar 2000 10:16:41 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4F99252AB; Fri, 3 Mar 2000 10:13:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B20A252C4; Fri, 3 Mar 2000 10:13:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B4A5152AB for ; Fri, 3 Mar 2000 10:13:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 10:11:28 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Fri Mar 3 10:08:56 EST 2000 Received: from cisco.com (localhost [127.0.0.1]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA06393; Fri, 3 Mar 2000 10:10:22 -0500 (EST) Message-ID: <38BFD5DD.3472F7C6@cisco.com> Date: Fri, 03 Mar 2000 10:10:22 -0500 From: Sudipto Mukherjee Organization: Cisco X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: schulzrinne@cs.columbia.edu, Jonathan Rosenberg , sip@lists.research.bell-labs.com, sudiptom@cisco.com Subject: Re: Tag in 200 OK response for CANCEL References: <65256897.0014BB33.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Arjun, > > sm> Also, does a UAC receiving a BYE (Called Party Release) need to add > > sm> a tag in the "To" header of the 200 OK response ? The From header > > sm> in BYE has a tag but there is *no* tag in the To header. > This scenario will happen in a normal case (when UAS initiates disconnect) and not necessarily when the sending side is broken. UAC UAS INV From:UAC, To:UAS ------------------------------> 200 OK (From:UAC, To:UAS;tag=123 <------------------------------ ACK (From:UAC, To:UAS;tag=123) --------------------------------> BYE(From:UAS;tag=123, To:UAC) <------------------------------- 200 OK (From:UAS;tag=123, To:UAC) --------------------------------> Now if the Called Party disconnects, the BYE generated by the UAS will *not* have a Tag in the To header. The From header has the tag, in this case. From and To are flipped when the request is generated by UAS. As I understood from Jonathan's reply, the From and To (including the tags) are established during call setup phase and should remain the same for subsequent transactions within the same call. Hence there is no need for the UAC to add a tag in the BYE 200 OK response. Thanks - Sudipto archow@hss.hns.com wrote: > > Hi, > With Henning's clarification of the para,: > > hgs> A UAS or redirect server {\MUST} add a ``\header{tag}'' parameter for > hgs> all final responses for all transactions within a call leg. All such > hgs> parameters have the same value within the same call leg. These > hgs> servers {\MAY} add the \header{tag} for informational responses during > hgs> the initial {\INVITE} transaction, but {\MUST} add a tag to > hgs> informational responses for all subsequent transactions. > > relooking at the initial question which Sudipto asked: > > > sm> Also, does a UAC receiving a BYE (Called Party Release) need to add > > sm> a tag in the "To" header of the 200 OK response ? The From header > > sm> in BYE has a tag but there is *no* tag in the To header. > > Can one conclude that the above case will never happen as before BYE, when > the first > INVITE reaches the UAS without a tag, it MUST add the tag in its 200 OK. > Now this tag MUST > be the used in all subsequent transactions, so receiving a second > transaction without a tag > can never happen, unless the sending side is broken ? And in the case it is > broken, ie BYE comes > now without a tag (though the UAS had send 200OK for INV with a tag) , the > UAS cant match the response since the call -leg does not match. He discards > it ? (or does he accept it?) > If the above is true, then tag is only needed to be added in the first > transaction, isnt it ? > > Thanks > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > archow@hns.com on 03/02/2000 02:26:14 PM > > To: Jonathan Rosenberg > cc: archow, Sudipto Mukherjee , > sip@lists.research.bell-labs.com > > Subject: Re: Tag in 200 OK response for CANCEL > > Hi, > Im a little confused here. > my understaning was that a UA receiving a message with more than one Via or > a mcast address in it MUST add a tag. > Even if say, A sent an INVITE to B thru some proxy P which forked, B now > gets the INVITE and puts a tag in its 200 OK since there are now 2 Vias. A > gets the 200 OK with the tag that B inserted. however A did not know of the > Tag when it sent it . > However, this tagged response is the matching response for a request which > A sent which was not tagged by itself. > So isnt this scenario same as the case for subsequent requests with > messages sent without a tag ? > > Now are we saying that the above specification of inserting tags by UAs > holds true only for the first transaction of a call leg and not any more ? > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > > sm> Also, does a UAC receiving a BYE (Called Party Release) need to add > > sm> a tag in the "To" header of the 200 OK response ? The From header > > sm> in BYE has a tag but there is *no* tag in the To header. > > > > Yes, again I think it should. A "tag" in the From field is used if > multiple > > callers use the same From address. This has nothing to do with forking of > > messages by proxies as such. > > jr> I disagree here as well. The local and remote addresses (obtained from > jr> the To and From fields, including the tags) that identify the call leg > jr> are established upon call setup, and remain fixed for the duration of > jr> the call leg. Adding a tag in a subsequent request (BYE or re-INVITE) > is > jr> going to alter this identifier and likely cause one side or the other > to > jr> not be able to match requests or responses to a particular call leg. -- --------------------------------------------------------------------------- Sudipto Mukherjee Cisco Systems, Inc sudiptom@cisco.com 7025 Kit Creek Rd 919-392-5780 PO Box 14987 Research Triangle Park, NC 27709 -------------------------------------------------------------------------- From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 10:20:46 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00124 for ; Fri, 3 Mar 2000 10:20:46 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 668E152C8; Fri, 3 Mar 2000 10:17:37 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A29F152C4; Fri, 3 Mar 2000 10:17:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A2D5152DC for ; Fri, 3 Mar 2000 10:17:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 10:16:50 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Fri Mar 3 10:14:18 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FQU007AWQF7TQ@firewall.mcit.com> for sip@lists.research.bell-labs.com; Fri, 3 Mar 2000 15:16:19 +0000 (GMT) Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id PAA08619; Fri, 03 Mar 2000 15:16:20 +0000 (GMT) Received: from i5f0a2 ([166.35.147.118]) by omta4.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000303151823.FZEI30350@i5f0a2>; Fri, 03 Mar 2000 15:18:23 +0000 Date: Fri, 03 Mar 2000 09:10:19 -0600 From: Kevin Summers Subject: RE: Information request! (Billing Package?) In-reply-to: <000101bf83af$3f565080$a6e123a6@mcit.com> To: Dean Willis , Nathan Nelson , "Rosen, Brian" Cc: sip@lists.research.bell-labs.com Reply-To: Kevin.Summers@wcom.com Message-id: <016c01bf8522$96f53da0$769323a6@i5f0a2.mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit This would appear to be something more in the AAA WG realm, not a SIP WG item. Kevin Summers Global Network Evolution MCI Worldcom > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Dean Willis > Sent: Wednesday, March 01, 2000 12:52 PM > To: Nathan Nelson; Rosen, Brian > Cc: sip@lists.research.bell-labs.com > Subject: RE: Information request! (Billing Package?) > > > > My sponsors would certainly be interested in a complete and standard CDR > format that would be supported by multiple vendors. > > Is that a SIP WG item? > > As I understand it this sort of accounting work is in the domain > of the AAA > (Authentication, Authorization, Accounting) working group. As we're > currently using RADIUS to throw most of our CDRs, and RADIUS is in AAA, > that's where I've been sending CDR issues. > > -- > Dean > > > > -----Original Message----- > > From: owner-sip@lists.research.bell-labs.com > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Nathan > > Nelson > > Sent: Wednesday, March 01, 2000 8:51 AM > > To: Rosen, Brian > > Cc: sip@lists.research.bell-labs.com > > Subject: Re: Information request! (Billing Package?) > > > > > > The point that was being ask is not specific to SIP, but more > general to a > > decomposed architectures. > > > > The current formats that are used to bill PSTN traffic are based > > on AMA BAF or > > a carrier/vendor defined CDR. Inet believes there is a need to build a > > standard format for a Transaction over IP record that allows for > > elements and > > parameters to be recorded. > > > > Some of the key components of this record could be: > > > > A Tracking field to tie multiple records from multiple > > platforms together > > Time Stamps > > Usage Stamps > > Originating Information (PSTN Number, IP address, email > address.....) > > Terminating Information (PSTN Number, IP address, email address....) > > Terminating Port/ Media Gateway > > Originating Port/Media Gateway > > Amount of bandwidth used > > Types of Applications used > > Premiums associated with Applications > > Application Information (Application server IP addresses) > > Intermediate network usage > > > > One of the basic issues with a decomposed architecture from an > accounting > > aspect is that multiple devices are involved in call set, > > routing, application > > usage, signaling, and finally termination. It would be nice to see IETF > > support a group that looks at accountability and billing, or at > > least provide > > a basic model to build such records. > > > > Thx, > > Nate Nelson > > Inet > > > > "Rosen, Brian" wrote: > > > > > Interesting, I assumed everything EXCEPT a gateway throws CDRs. > > > Assuming a decomposed gateway, the GW feeds statistics to a Call Agent > > > (which would be a SIP UA among other things) that throws CDRs. > > > > > > The billing system collates all the CDRs. > > > > > > The spec required is, of course, the format of the CDR and > the way they > > > are transported. You could claim that a "transaction log" is > a form of > > > CDR I suppose. > > > > > > I'd certainly agree that SIP itself doesn't have any "billing > package". > > > A UA and a server might, but that is independent of the > > protocol. Billing > > > might very well impact some things in SIP. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Dean Willis [mailto:dean.willis@wcom.com] > > > > Sent: Tuesday, February 29, 2000 2:41 PM > > > > To: Mart Nurmet; sip@lists.research.bell-labs.com > > > > Subject: RE: Information request! (Billing Package?) > > > > > > > > > > > > What would a billing package look like? I've never really > > > > understood the > > > > concept, and it might be useful to talk about it some more. > > > > > > > > Here's how some implementors are doing it: > > > > > > > > 1) Gateways throw CDRs using RADIUS or something similar. > > > > This feeds into > > > > rating, reporting, and billing systems, > > > > > > > > 2) SIP servers record transaction logs. These may feed into > rating and > > > > billing systems, and probably feed into reporting systems. > > > > > > > > 3) QoS PEP and PDPs log resource usages. These feed > upstream as well. > > > > > > > > 4) Other systems, like profile managers, report usage. > > > > > > > > 5) Rating, reporting, and billing systems sift thru the vast > > > > amounts of > > > > information coming at them and make useful things happen. > > > > > > > > All of these things use other protocols and systems -- they > aren't SIP > > > > specific. They do rely on SIP functions like authentication > > > > -- that is, the > > > > goal of achieving billing functions has driven some > > > > requirements into the > > > > design of SIP. However, other than driving some requirements > > > > to SIP, such > > > > efforts are generally considered to be outside the scope of > > > > the SIP WG. > > > > > > > > Are you perhaps proposing to add functionality to SIP to > > > > simplify or enhance > > > > reporting capabilities or to simplify the task of driving > > > > downstream billing > > > > systems? > > > > > > > > -- > > > > Dena > > > > > -----Original Message----- > > > > > From: owner-sip@lists.research.bell-labs.com > > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of > > > > Mart Nurmet > > > > > Sent: Monday, February 28, 2000 2:24 PM > > > > > To: sip@lists.research.bell-labs.com > > > > > Subject: Information request! (Billing Package?) > > > > > > > > > > > > > > > I am looking for information if there has been any work > > > > done to generate a > > > > > billing package for SIP. From my look at the available > > > > > information there does > > > > > not seem to be any. Is that the case or am I missing something? > > > > > > > > > > Thank you, > > > > > -Mart > > > > > > > > > > > > > > > > > > > > > > > > From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 10:45:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01005 for ; Fri, 3 Mar 2000 10:45:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4143E52B6; Fri, 3 Mar 2000 10:43:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A67E552D4; Fri, 3 Mar 2000 10:43:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id DCFC952B6 for ; Fri, 3 Mar 2000 10:43:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 3 10:43:03 EST 2000 Received: from smtprch1.nortel.com ([192.135.215.14]) by dusty; Fri Mar 3 10:40:31 EST 2000 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Fri, 3 Mar 2000 09:42:14 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Mar 2000 09:42:03 -0600 Message-ID: From: "Glenn Morrow" To: "'Jonathan Rosenberg'" , yinshaohua Cc: Igor Slepchin , sip@lists.research.bell-labs.com Subject: RE: Stateful/Stateless proxies Date: Fri, 3 Mar 2000 09:42:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8527.03C7E938" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF8527.03C7E938 Content-Type: text/plain Do you mean call or transactionally stateful? > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > Sent: Friday, March 03, 2000 1:08 AM > To: yinshaohua > Cc: Igor Slepchin; sip@lists.research.bell-labs.com > Subject: Re: Stateful/Stateless proxies > > > > yinshaohua wrote: > > > > Hi: > > Now that " A single physical proxy may act as stateless in some > > situations and as stateful in others" , what role do we comply with when > > making a proxy stateful or stateless after receiving a INVITE request? > > Whichever you want, depening on what it is you wish to accomplish. Its > based on administrator policy, the service being invoked, or whatever. > The only rules are: > > 1. if you send TCP, you have to be stateful > 2. if you send multicast, you have to be stateful > 3. if you fork, you have to be stateful > > -Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > ------_=_NextPart_001_01BF8527.03C7E938 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Stateful/Stateless proxies

Do you mean call or = transactionally stateful?

    -----Original Message-----
    From:   Jonathan Rosenberg = [SMTP:jdrosen@dynamicsoft.com]
    Sent:   Friday, March 03, 2000 1:08 AM
    To:     yinshaohua
    Cc:     Igor Slepchin; sip@lists.research.bell-labs.com
    Subject:       = Re: Stateful/Stateless = proxies



    yinshaohua wrote:
    >
    > Hi:
    >     Now that = " A single physical proxy may act as stateless in some
    > situations and as stateful in = others" , what role do we comply with when
    > making a proxy stateful or = stateless after receiving a INVITE request?

    Whichever you want, depening on what = it is you wish to accomplish. Its
    based on administrator policy, the = service being invoked, or whatever.
    The only rules are:

    1. if you send TCP, you have to be = stateful
    2. if you send multicast, you have to = be stateful
    3. if you fork, you have to be = stateful

    -Jonathan R.
    --
    Jonathan D. = Rosenberg          &nb= sp;            = 200 Executive Drive
    Chief = Scientist          &nb= sp;           &nb= sp;      Suite 120
    dynamicsoft       &nbs= p;           &nbs= p;           &nbs= p; West Orange, NJ 07052
    jdrosen@dynamicsoft.com     &nbs= p;           &nbs= p;   FAX:   (732) 741-4778
    http://www.cs.columbia.edu/~jdrosen         PHONE: = (732) 741-7244
    http://www.dynamicsoft.com

------_=_NextPart_001_01BF8527.03C7E938-- From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 10:57:41 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01448 for ; Fri, 3 Mar 2000 10:57:40 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D229252D4; Fri, 3 Mar 2000 10:53:37 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 14B3E52D6; Fri, 3 Mar 2000 10:53:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DAD0152D4 for ; Fri, 3 Mar 2000 10:53:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 10:52:14 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Fri Mar 3 10:49:42 EST 2000 Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA25193; Fri, 3 Mar 2000 10:52:08 -0500 (EST) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.1/8.9.1) id KAA23011; Fri, 3 Mar 2000 10:52:08 -0500 (EST) Date: Fri, 3 Mar 2000 10:52:08 -0500 (EST) Message-Id: <200003031552.KAA23011@ind.cs.columbia.edu> From: Jonathan Lennox To: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com, cgi-wg@golux.com Cc: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com Subject: Informal Last Call: Common Gateway Interface for SIP Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk With the submission of the most recent version of the SIP Common Gateway Interface, we'd like to announce an informal Last Call on this document (in place of a Working Group last call, since this draft has no associated working group). We'll solicit comments for four weeks, until March 31, 2000. At that time we'll submit this draft for Informational RFC status. Comments on the draft should be sent to the SIP mailing list sip@lists.research.bell-labs.com, or to the authors. Title : Common Gateway Interface for SIP Author(s) : J. Lennox, J. Rosenberg, H. Schulzrinne Filename : draft-lennox-sip-cgi-03.txt,.ps Pages : 38 Date : 02-Mar-00 In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the Common Gateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between the Session Initiation Protocol (SIP) and the Hyper Text Transfer Protocol (HTTP), CGI seems a good candidate for service creation in a SIP environment. This draft proposes a SIP-CGI interface for providing SIP services on a SIP server. URLs for this Internet-Draft are: http://www.ietf.org/internet-drafts/draft-lennox-sip-cgi-03.txt http://www.ietf.org/internet-drafts/draft-lennox-sip-cgi-03.ps http://www.cs.columbia.edu/~lennox/draft-lennox-sip-cgi-03.pdf The Postscript and PDF versions contain changebars indicating changes from the previous version. -- Jonathan Lennox lennox@cs.columbia.edu From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 11:12:27 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01952 for ; Fri, 3 Mar 2000 11:12:26 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A32C152D6; Fri, 3 Mar 2000 11:09:28 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 117CC52D5; Fri, 3 Mar 2000 11:09:27 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7E55652D6 for ; Fri, 3 Mar 2000 11:09:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 11:08:34 EST 2000 Received: from mailserv2.iuinc.com ([206.245.164.55]) by dusty; Fri Mar 3 11:06:03 EST 2000 Received: (qmail 1271 invoked from network); 3 Mar 2000 16:08:33 -0000 Received: from unknown (HELO Adoyle) (216.181.56.35) by mailserv2.iuinc.com with SMTP; 3 Mar 2000 16:08:33 -0000 From: "Alex Doyle" To: "Jonathan Rosenberg" , "Michael Pham" Cc: , , Subject: RE: Call Transfer and Requested-By Date: Fri, 3 Mar 2000 11:10:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-reply-to: <38BF5431.7C32BF67@dynamicsoft.com> Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan, Michael -- I'm not sure I agree -- isn't there a distinction here between: - call redirection (forwarding to a User's new location) - user forwarding (forwarding to a new User) If you're talking about "forwarding" with the 3xx Redirection, then that isn't really true User forwarding, it's more like User mobility. If A calls B, and B's server redirects, then the call is being redirected to a new location on behalf of B. B is still the terminating party, and still the party that would send a BYE(Also), right? If you're talking about User forwarding (A calls B, B forwards to C), well, that's a separate problem. I'd argue that you wouldn't use a 3xx Redirection for that call...because your To: field won't be correct. (Maybe that service is done better by making the server act like a back-to-back UA.) I still don't see the basic need for an endpoint adding the Requested-By to the BYE(Also) -- it seems like the From field in the BYE should always be sufficient to identify the endpoint requesting the transfer. If it *isn't* sufficient, then I'd argue that perhaps the initial INVITE wasn't correct. Comments? Alex -----Original Message----- From: owner-sip@lists.research.bell-labs.com [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Friday, March 03, 2000 12:57 AM To: Michael Pham Cc: sip@lists.research.bell-labs.com; manojb@cisco.com; sudiptom@cisco.com Subject: Re: Call Transfer and Requested-By Good question. The original thinking is that it would be populated with the From field of the BYE. However, if the original call was forwarded, the From field isn't going to be the actual person doing the transfer. Unfortunately, the multiparty conferencing stuff relies on the From field being what is used in Requested-By. Ignoring that problem for the moment, considering just transfer, Contact isn't the right thing either. The address in Contact is usually a fully qualified hostname, when you want something thats more of a logical identifier. An alternative would be to actually have a Requested-By header in the BYE itself, and the URL in there is copied into the INVITE triggere from the transfer. -Jonathan R. Michael Pham wrote: > > Could someone comment on how the Requested-By header should be populated > in a blind transfer scenario where Requested-By is included in the > Invite request sent to the transferred-to party? It's my understanding > that Requested-By should identify the party initiating the transfer so > using the From/To header (from the Bye) does not always guarantee the > true endpoint requesting the transfer. Would using the Contact header be > more appropriate? > > Regards, > Michael -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 12:33:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04325 for ; Fri, 3 Mar 2000 12:33:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E31AC52C4; Fri, 3 Mar 2000 12:31:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5419852DB; Fri, 3 Mar 2000 12:31:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id BB18E52C4 for ; Fri, 3 Mar 2000 12:31:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 3 12:29:56 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Mar 3 12:27:24 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA16945; Fri, 3 Mar 2000 12:29:02 -0500 (EST) Message-ID: <38BFF795.E347A4DC@dynamicsoft.com> Date: Fri, 03 Mar 2000 12:34:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow Cc: yinshaohua , Igor Slepchin , sip@lists.research.bell-labs.com Subject: Re: Stateful/Stateless proxies References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Yes. When the SIP spec says "stateful", thats "transaction stateful". -Jonathan R. > Glenn Morrow wrote: > > Do you mean call or transactionally stateful? > > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > Sent: Friday, March 03, 2000 1:08 AM > To: yinshaohua > Cc: Igor Slepchin; sip@lists.research.bell-labs.com > Subject: Re: Stateful/Stateless proxies > > yinshaohua wrote: > > > > Hi: > > Now that " A single physical proxy may act as stateless in > some > > situations and as stateful in others" , what role do we comply > with when > > making a proxy stateful or stateless after receiving a INVITE > request? > > Whichever you want, depening on what it is you wish to > accomplish. Its > based on administrator policy, the service being invoked, or > whatever. > The only rules are: > > 1. if you send TCP, you have to be stateful > 2. if you send multicast, you have to be stateful > 3. if you fork, you have to be stateful > > -Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 13:38:29 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05888 for ; Fri, 3 Mar 2000 13:38:26 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7D8EF52DC; Fri, 3 Mar 2000 13:35:32 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C8C4052DD; Fri, 3 Mar 2000 13:35:31 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9129D52DC for ; Fri, 3 Mar 2000 13:35:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 13:33:37 EST 2000 Received: from hvmta02-stg.us.psimail.psi.net ([38.202.36.30]) by dusty; Fri Mar 3 13:31:06 EST 2000 Received: from software_OL ([38.150.216.39]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20000303183335.KTPE6211.hvmta02-stg@software_OL> for ; Fri, 3 Mar 2000 13:33:35 -0500 Message-ID: <008f01bf853e$e21a3c60$27d89626@software_OL.radvision.com> Reply-To: "Orit Levin" From: "Orit Levin" To: "SIP reflector" Subject: DHCP option tags for SIP(?) Date: Fri, 3 Mar 2000 13:32:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01BF8514.F911D9C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_008C_01BF8514.F911D9C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello! Sorry for bringing this issue once again. It is not about the necessity of the proposed procedure. I think it is = useful and should be pursued. My attitude is that end devices may = support more then one procedure for the same purpose (especially when it = is a configuration issue). In this way they are flexible and can be = deployed in various environments. My concern is that the functionality described in the current proposal = is by no means SIP-specific. There are many APPLICATION LEVEL protocols = that require this functionality, i.e. they relay on application-specific = Server (or a list of possible Servers), whose IP address(es) should be = discovered at bootstrap. Academically thinking it is strange to allocate = "a whole DHCP option" to one specific application.=20 Practically thinking, the best example in VoIP area is MEGACO which is = "heavily dependant" on its Server(s). From VoIP terminal, flexibly = implementing both SIP and MEGACO, I would expect it to use the same = bootstrap procedure for both applications. Looking into the "Procedure for Defining New DHCP Options" RFC-2489 you = will find that "the option number space for publicly defined DHCP = options has almost been exhausted" and this is the whole reason for the = new procedure defined by RFC-2489. Based on this, I would like to suggest SIP Working group to revise their = proposal by defining the use of this option in flexible "application = level" point of view. Best Regards, Orit Levin RADVision Inc. Director of Product Management 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com ------=_NextPart_000_008C_01BF8514.F911D9C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello!
Sorry for bringing this issue once again.
 
It is not about the necessity of the proposed procedure. I=20 think it is useful and should be pursued. My attitude is that end=20 devices may support more then one procedure for the same purpose=20 (especially when it is a configuration issue).  In this way=20 they are flexible and can be deployed in various=20 environments.
 
My concern is that the functionality described = in the=20 current proposal is by no means SIP-specific. There are = many APPLICATION=20 LEVEL protocols that require this functionality, i.e. they relay on=20 application-specific Server (or a list of possible Servers), whose IP=20 address(es) should be discovered at bootstrap. Academically thinking it = is=20 strange to allocate "a whole DHCP option" to one specific = application.=20
 
Practically thinking, the best example in VoIP area is = MEGACO=20 which is "heavily dependant" on its Server(s). From VoIP terminal, = flexibly=20 implementing both SIP and MEGACO, I would expect it to use the same = bootstrap=20 procedure for both applications.
 
Looking into the "Procedure for Defining New DHCP = Options"=20 RFC-2489 you will find that "the option number space for publicly = defined DHCP=20 options has almost been exhausted" and this is the whole reason for the = new=20 procedure defined by RFC-2489.
 
Based on this, I would like to suggest SIP Working = group to=20 revise their proposal by defining the use of this option = in flexible =20 "application level" point of view.
 
Best Regards,
Orit Levin
RADVision Inc.
Director of Product Management
575 Corporate = Drive Suite=20 420
Mahwah, NJ 07430
Tel: 1 201 529 4300  (230)
Fax: 1 201 = 529=20 3516
www.radvision.com
orit@radvision.com
------=_NextPart_000_008C_01BF8514.F911D9C0-- From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 13:51:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06155 for ; Fri, 3 Mar 2000 13:51:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1D86352DB; Fri, 3 Mar 2000 13:49:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9AC9452DD; Fri, 3 Mar 2000 13:49:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C692752DB for ; Fri, 3 Mar 2000 13:49:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 13:49:04 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Fri Mar 3 13:46:31 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA16400; Fri, 3 Mar 2000 13:48:46 -0500 (EST) Message-ID: <38C0090C.48EFF483@cs.columbia.edu> Date: Fri, 03 Mar 2000 13:48:44 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Orit Levin Cc: SIP reflector Subject: Re: DHCP option tags for SIP(?) References: <008f01bf853e$e21a3c60$27d89626@software_OL.radvision.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > Orit Levin wrote: > > Hello! > Sorry for bringing this issue once again. > > It is not about the necessity of the proposed procedure. I think it is > useful and should be pursued. My attitude is that end devices may > support more then one procedure for the same purpose (especially when > it is a configuration issue). In this way they are flexible and can > be deployed in various environments. > > My concern is that the functionality described in the current proposal > is by no means SIP-specific. There are many APPLICATION LEVEL > protocols that require this functionality, i.e. they relay on > application-specific Server (or a list of possible Servers), whose IP > address(es) should be discovered at bootstrap. Academically thinking > it is strange to allocate "a whole DHCP option" to one specific > application. Actually, if you look at the current DHCP options, that's exactly how it works: SMTP and WWW, to name just two examples, have their own options, as do time servers, font servers, etc. - all applications. > > Practically thinking, the best example in VoIP area is MEGACO which is > "heavily dependant" on its Server(s). From VoIP terminal, flexibly > implementing both SIP and MEGACO, I would expect it to use the same > bootstrap procedure for both applications. > > Looking into the "Procedure for Defining New DHCP Options" RFC-2489 > you will find that "the option number space for publicly defined DHCP > options has almost been exhausted" and this is the whole reason for > the new procedure defined by RFC-2489. > > Based on this, I would like to suggest SIP Working group to revise > their proposal by defining the use of this option in flexible > "application level" point of view. Since I'm not sure what exactly you propose, but... The problem is two-fold: a) Many systems don't need all of H.323, Megaco, SIP, whatever. Given the limited space in DHCP payloads, overloading a single option with multiple sub-options means that the client can't choose which ones it needs. (E.g., a SIP phone would not care the least about Megaco servers.) b) Implementation: All existing DHCP servers are limited to either strings or a list of IP addresses. Adding suboptions means that existing servers can't be used. Waiting until DHCP servers incorporate this special option could take years, not even counting the installed-base issue of WinNT4 servers, etc. > > Best Regards, > Orit Levin > RADVision Inc. > Director of Product Management > 575 Corporate Drive Suite 420 > Mahwah, NJ 07430 > Tel: 1 201 529 4300 (230) > Fax: 1 201 529 3516 > www.radvision.com > orit@radvision.com -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 14:22:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06989 for ; Fri, 3 Mar 2000 14:22:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 59E4E52D6; Fri, 3 Mar 2000 14:19:32 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BC01F52DD; Fri, 3 Mar 2000 14:19:31 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 98AC552D6 for ; Fri, 3 Mar 2000 14:19:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 14:18:18 EST 2000 Received: from hvmta02-stg.us.psimail.psi.net ([38.202.36.30]) by dusty; Fri Mar 3 14:15:47 EST 2000 Received: from software_OL ([38.150.216.39]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20000303191816.LDHJ6211.hvmta02-stg@software_OL>; Fri, 3 Mar 2000 14:18:16 -0500 Message-ID: <00b701bf8545$1ee7ab40$27d89626@software_OL.radvision.com> Reply-To: "Orit Levin" From: "Orit Levin" To: "Henning Schulzrinne" Cc: "SIP reflector" Subject: Re: DHCP option tags for SIP(?) Date: Fri, 3 Mar 2000 14:17:30 -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 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning, thanks for the answer. Clarifications are below. >Actually, if you look at the current DHCP options, that's exactly how it >works: SMTP and WWW, to name just two examples, have their own options, >as do time servers, font servers, etc. - all applications. > 1. I can just imagine that this exact policy led to the exhaustion of the DHCP option tag space. This is exactly the attitude RFC-2489 tries to prevent. We should start from some point in time to follow the new policy! 2. In the current situation (with "limited" DHCP servers in place) the VoIP end device would be pre-configured with the kind of "VoIP" protocol they should start first. The meaning of my proposal is (1) to introduce tag saying something like "Call Control Server" ("VoIP" is really limiting) (2) in addition to that and becoming the first (?) positive example, the definition for flexible sub-options field should/may be introduced. Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com -----Original Message----- From: Henning Schulzrinne To: Orit Levin Cc: SIP reflector Date: Friday, March 03, 2000 1:48 PM Subject: Re: DHCP option tags for SIP(?) >> Orit Levin wrote: >> >> Hello! >> Sorry for bringing this issue once again. >> >> It is not about the necessity of the proposed procedure. I think it is >> useful and should be pursued. My attitude is that end devices may >> support more then one procedure for the same purpose (especially when >> it is a configuration issue). In this way they are flexible and can >> be deployed in various environments. >> >> My concern is that the functionality described in the current proposal >> is by no means SIP-specific. There are many APPLICATION LEVEL >> protocols that require this functionality, i.e. they relay on >> application-specific Server (or a list of possible Servers), whose IP >> address(es) should be discovered at bootstrap. Academically thinking >> it is strange to allocate "a whole DHCP option" to one specific >> application. > >Actually, if you look at the current DHCP options, that's exactly how it >works: SMTP and WWW, to name just two examples, have their own options, >as do time servers, font servers, etc. - all applications. > >> >> Practically thinking, the best example in VoIP area is MEGACO which is >> "heavily dependant" on its Server(s). From VoIP terminal, flexibly >> implementing both SIP and MEGACO, I would expect it to use the same >> bootstrap procedure for both applications. >> >> Looking into the "Procedure for Defining New DHCP Options" RFC-2489 >> you will find that "the option number space for publicly defined DHCP >> options has almost been exhausted" and this is the whole reason for >> the new procedure defined by RFC-2489. >> >> Based on this, I would like to suggest SIP Working group to revise >> their proposal by defining the use of this option in flexible >> "application level" point of view. > >Since I'm not sure what exactly you propose, but... > >The problem is two-fold: > >a) Many systems don't need all of H.323, Megaco, SIP, whatever. Given >the limited space in DHCP payloads, overloading a single option with >multiple sub-options means that the client can't choose which ones it >needs. (E.g., a SIP phone would not care the least about Megaco >servers.) > >b) Implementation: All existing DHCP servers are limited to either >strings or a list of IP addresses. Adding suboptions means that existing >servers can't be used. Waiting until DHCP servers incorporate this >special option could take years, not even counting the installed-base >issue of WinNT4 servers, etc. > > >> >> Best Regards, >> Orit Levin >> RADVision Inc. >> Director of Product Management >> 575 Corporate Drive Suite 420 >> Mahwah, NJ 07430 >> Tel: 1 201 529 4300 (230) >> Fax: 1 201 529 3516 >> www.radvision.com >> orit@radvision.com > >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs > From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 14:36:17 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07316 for ; Fri, 3 Mar 2000 14:36:15 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 74D8952E1; Fri, 3 Mar 2000 14:33:34 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AA6EE52DF; Fri, 3 Mar 2000 14:33:32 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8021C52DD for ; Fri, 3 Mar 2000 14:33:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 14:32:17 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Fri Mar 3 14:29:45 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA23776; Fri, 3 Mar 2000 14:32:07 -0500 (EST) Message-ID: <38C01335.B717D259@cs.columbia.edu> Date: Fri, 03 Mar 2000 14:32:05 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Orit Levin Cc: SIP reflector Subject: Re: DHCP option tags for SIP(?) References: <00b701bf8545$1ee7ab40$27d89626@software_OL.radvision.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Orit Levin wrote: > > > 2. In the current situation (with "limited" DHCP servers in place) the VoIP > end device would be pre-configured with the kind of "VoIP" protocol they > should start first. The meaning of my proposal is > (1) to introduce tag saying something like "Call Control Server" ("VoIP" is > really limiting) I'm afraid I don't follow how this would look like in bits and bytes. > (2) in addition to that and becoming the first (?) positive example, the > definition for flexible sub-options field should/may be introduced. Besides being a positive example, I also want to be able to deploy systems before 2010. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 18:23:47 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11822 for ; Fri, 3 Mar 2000 18:23:46 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 77B1552B6; Fri, 3 Mar 2000 18:21:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E90CE52C4; Fri, 3 Mar 2000 18:21:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D739652B6 for ; Fri, 3 Mar 2000 18:21:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 18:19:13 EST 2000 Received: from zipper.cisco.com ([171.69.63.31]) by dusty; Fri Mar 3 18:16:42 EST 2000 Received: (manjax@localhost) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id PAA16752 for sip@lists.research.bell-labs.com; Fri, 3 Mar 2000 15:19:12 -0800 (PST) From: Manjunath Bangalore Message-Id: <200003032319.PAA16752@zipper.cisco.com> Subject: SIP 1xx Response... To: sip@lists.research.bell-labs.com Date: Fri, 3 Mar 2000 15:19:11 -0800 (PST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi! I had a question about the usage of the SIP "100 Trying" response message. I wanted to know if it is acceptable to include a SIP message body with a session description. I see a reference in Section 8.1 of the RFC that all responses MAY include a body. I wanted to get more information regarding this in the context of the "100 Trying" Response. Thanks, -Manjax From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 18:29:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11906 for ; Fri, 3 Mar 2000 18:29:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C38C552C8; Fri, 3 Mar 2000 18:27:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 36EBA52C4; Fri, 3 Mar 2000 18:27:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CC9C552C8 for ; Fri, 3 Mar 2000 18:27:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 18:26:00 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Fri Mar 3 18:23:29 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id SAA03228; Fri, 3 Mar 2000 18:25:57 -0500 (EST) Message-ID: <38C04A05.AEA10C8C@cisco.com> Date: Fri, 03 Mar 2000 18:25:57 -0500 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Manjunath Bangalore Cc: sip@lists.research.bell-labs.com Subject: Re: SIP 1xx Response... References: <200003032319.PAA16752@zipper.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Manjunath Bangalore wrote: > > Hi! > I had a question about the usage of the SIP "100 Trying" > response message. I wanted to know if it is acceptable to > include a SIP message body with a session description. > I see a reference in Section 8.1 of the RFC that all > responses MAY include a body. I wanted to get more information > regarding this in the context of the "100 Trying" Response. > > Thanks, > -Manjax 100 would be consumed by the stateful proxy - so there is no point including it in the "100 Trying" response. -- Best regards, Shail From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 3 18:41:46 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12099 for ; Fri, 3 Mar 2000 18:41:46 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 950B552AB; Fri, 3 Mar 2000 18:39:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 138C352D4; Fri, 3 Mar 2000 18:39:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9B59D52AB for ; Fri, 3 Mar 2000 18:39:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 18:37:35 EST 2000 Received: from zipper.cisco.com ([171.69.63.31]) by dusty; Fri Mar 3 18:35:04 EST 2000 Received: (manjax@localhost) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id PAA18282; Fri, 3 Mar 2000 15:37:33 -0800 (PST) From: Manjunath Bangalore Message-Id: <200003032337.PAA18282@zipper.cisco.com> Subject: Re: SIP 1xx Response... To: shbhatna@cisco.com (Shail Bhatnagar) Date: Fri, 3 Mar 2000 15:37:27 -0800 (PST) Cc: sip@lists.research.bell-labs.com, rajneesh@cisco.com (Rajneesh Kumar), njoffe@cisco.com (Neil Joffe) In-Reply-To: <38C04A05.AEA10C8C@cisco.com> from "Shail Bhatnagar" at Mar 03, 2000 06:25:57 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello, According to Shail Bhatnagar: > > Manjunath Bangalore wrote: > > > > Hi! > > I had a question about the usage of the SIP "100 Trying" > > response message. I wanted to know if it is acceptable to > > include a SIP message body with a session description. > > I see a reference in Section 8.1 of the RFC that all > > responses MAY include a body. I wanted to get more information > > regarding this in the context of the "100 Trying" Response. > > > > Thanks, > > -Manjax > > 100 would be consumed by the stateful proxy - so there is no point > including it in the "100 Trying" response. > Assuming there is no proxy in the scenario under consideration (eg: GW <---> GW), I wanted to know if it is acceptable to do that... Thanks, -Manjax From owner-sip-outgoing@lists.research.bell-labs.com Sat Mar 4 09:34:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04169 for ; Sat, 4 Mar 2000 09:34:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 71A9952D4; Sat, 4 Mar 2000 09:31:02 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CA74F52D5; Sat, 4 Mar 2000 09:31:01 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 12A1D52C4 for ; Fri, 3 Mar 2000 12:11:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 3 12:10:38 EST 2000 Received: from seattle.3com.com ([129.213.128.97]) by dusty; Fri Mar 3 12:08:07 EST 2000 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id JAA24636 for ; Fri, 3 Mar 2000 09:10:21 -0800 (PST) From: Anoop_Tripathi@3com.com Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id JAA13386 for ; Fri, 3 Mar 2000 09:10:21 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 88256897.005E51FF ; Fri, 3 Mar 2000 09:10:13 -0800 X-Lotus-FromDomain: 3COM To: sip@lists.research.bell-labs.com Message-ID: <88256897.005E4FB4.00@hqoutbound.ops.3com.com> Date: Fri, 3 Mar 2000 11:11:57 -0600 Subject: Where can I find the draft Sip BCP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, I was looking for the SIP : Best Current Practices draft ? Could someone point me to it. Thanks, Anoop From owner-sip-outgoing@lists.research.bell-labs.com Sat Mar 4 19:44:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09402 for ; Sat, 4 Mar 2000 19:44:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A36CF52C4; Sat, 4 Mar 2000 19:41:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 219A952DD; Sat, 4 Mar 2000 19:41:25 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CE98D52C4 for ; Sat, 4 Mar 2000 19:41:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Mar 4 19:40:30 EST 2000 Received: from l3mail02.level3.com ([209.244.1.161]) by dusty; Sat Mar 4 19:37:57 EST 2000 Received: by level3.com with Internet Mail Service (5.5.2448.0) id <149TMW44>; Sat, 4 Mar 2000 17:38:23 -0700 Message-ID: From: Aparna.Vemuri@Level3.com To: Anoop_Tripathi@3com.com, sip@lists.research.bell-labs.com Subject: RE: Where can I find the draft Sip BCP Date: Sat, 4 Mar 2000 17:32:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Anoop, I think you refer to the SIP-T effort. Try looking for: draft-zimmerer-sip-bcp-t-00.txt. Thanks, Aparna Aparna V. Level (3) Communications. -----Original Message----- From: Anoop_Tripathi@3com.com [mailto:Anoop_Tripathi@3com.com] Sent: Friday, March 03, 2000 10:12 AM To: sip@lists.research.bell-labs.com Subject: Where can I find the draft Sip BCP Hi, I was looking for the SIP : Best Current Practices draft ? Could someone point me to it. Thanks, Anoop From owner-sip-outgoing@lists.research.bell-labs.com Sun Mar 5 15:12:16 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11020 for ; Sun, 5 Mar 2000 15:12:15 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D85F452D5; Sun, 5 Mar 2000 15:09:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5126452DA; Sun, 5 Mar 2000 15:09:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BDA9752D5 for ; Sun, 5 Mar 2000 15:09:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 5 15:08:37 EST 2000 Received: from ns.fmmo.ca ([207.253.160.156]) by dusty; Sun Mar 5 15:06:04 EST 2000 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id PAA08259; Sun, 5 Mar 2000 15:11:53 -0500 Date: Sun, 5 Mar 2000 15:11:52 -0500 (EST) From: Francois Menard List Account To: Henning Schulzrinne Cc: "'sip@lists.research.bell-labs.com'" Subject: INVITE with RTP RR's to a different address ... In-Reply-To: <38BC024A.49552218@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Is there a quick way to require the RTP RR's to go to a different IP address than the originating party through a SIP INVITE ? -=Francois=- From owner-sip-outgoing@lists.research.bell-labs.com Sun Mar 5 15:37:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11182 for ; Sun, 5 Mar 2000 15:37:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 27ACC52DA; Sun, 5 Mar 2000 15:35:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8CDFB52DD; Sun, 5 Mar 2000 15:35:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id DC5D552DA for ; Sun, 5 Mar 2000 15:35:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sun Mar 5 15:34:26 EST 2000 Received: from ns.fmmo.ca ([207.253.160.156]) by dusty; Sun Mar 5 15:31:52 EST 2000 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id PAA08354; Sun, 5 Mar 2000 15:37:42 -0500 Date: Sun, 5 Mar 2000 15:37:42 -0500 (EST) From: Francois Menard List Account To: Colin Perkins Cc: Henning Schulzrinne , sip@lists.research.bell-labs.com, Terri Cali Subject: Re: SIP bakeoff registration now open In-Reply-To: <5215.952017325@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Would that also include RTCP compatibility tests ? -=Francois=- On Thu, 2 Mar 2000, Colin Perkins wrote: > --> Henning Schulzrinne writes: > >http://www.sipbakeoff.org/4/ has details. Please contact Terri Cali > >(cc'ed) with any questions. > > > >I look forward to seeing many of you at the bake-off. > > > >I'd also appreciate feedback on whether and to what extent we should > >test more formally for RTP interoperability at this event. This has > >become an issue as we cannot progress RTP to draft status without more > >implementations that comply. Since a phone that only rings but doesn't > >"talk" is of somewhat limited use, this might be of some interest. (This > >would obviously only affect UAs, not servers.) > > I'd strongly support moves to perform RTP interoperability testing at the > SIP bakeoff. The AVT working group has produced a number of internet drafts > listing those features which would need to be tested and suggesting testing > procedures: > > draft-ietf-avt-rtp-interop-02.txt > draft-ietf-avt-profile-interop-00.txt > draft-ietf-avt-rtptest-02.txt > > And as Henning says, this demonstration must be completed before the revised > RTP specification can become an RFC. > > I would also encourage vendors who have performed in-house interoperability > testing of RTP implementations to consider making this information available > to the AVT working group chairs, so we can complete the interoperability > requirements (we're aware that some vendors have concerns with making this > available - contact us, and we can work to address them). > > Colin > From owner-sip-outgoing@lists.research.bell-labs.com Sun Mar 5 16:23:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11505 for ; Sun, 5 Mar 2000 16:23:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EC35052BB; Sun, 5 Mar 2000 16:21:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4BB1652DE; Sun, 5 Mar 2000 16:21:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A82DD52BB for ; Sun, 5 Mar 2000 16:21:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 5 16:19:58 EST 2000 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by dusty; Sun Mar 5 16:17:24 EST 2000 Received: from csperkins.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Sun, 5 Mar 2000 21:19:52 +0000 Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id VAA00791; Sun, 5 Mar 2000 21:21:01 GMT Message-Id: <200003052121.VAA00791@csperkins.demon.co.uk> To: Francois Menard List Account Cc: Henning Schulzrinne , sip@lists.research.bell-labs.com, Terri Cali Subject: Re: SIP bakeoff registration now open In-Reply-To: Message from Francois Menard List Account of "Sun, 05 Mar 2000 15:37:42 EST." Date: Sun, 05 Mar 2000 21:21:01 +0000 From: Colin Perkins Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --> Francois Menard List Account writes: >Would that also include RTCP compatibility tests ? In order to progress RTP to draft standard it is necessary to demonstrate interoperability of all options and features of the protocol. Accordingly, we need to have demonstrated RTCP along with the other features of RTP. Note that this doesn't imply that every implementation must implement every feature of RTP (although I would hope that all implement at least a minimal subset of RTCP), rather that every feature must be implemented in at least two implementations. Colin >On Thu, 2 Mar 2000, Colin Perkins wrote: > >> --> Henning Schulzrinne writes: >> >http://www.sipbakeoff.org/4/ has details. Please contact Terri Cali >> >(cc'ed) with any questions. >> > >> >I look forward to seeing many of you at the bake-off. >> > >> >I'd also appreciate feedback on whether and to what extent we should >> >test more formally for RTP interoperability at this event. This has >> >become an issue as we cannot progress RTP to draft status without more >> >implementations that comply. Since a phone that only rings but doesn't >> >"talk" is of somewhat limited use, this might be of some interest. (This >> >would obviously only affect UAs, not servers.) >> >> I'd strongly support moves to perform RTP interoperability testing at the >> SIP bakeoff. The AVT working group has produced a number of internet drafts >> listing those features which would need to be tested and suggesting testing >> procedures: >> >> draft-ietf-avt-rtp-interop-02.txt >> draft-ietf-avt-profile-interop-00.txt >> draft-ietf-avt-rtptest-02.txt >> >> And as Henning says, this demonstration must be completed before the revised >> RTP specification can become an RFC. >> >> I would also encourage vendors who have performed in-house interoperability >> testing of RTP implementations to consider making this information available >> to the AVT working group chairs, so we can complete the interoperability >> requirements (we're aware that some vendors have concerns with making this >> available - contact us, and we can work to address them). >> >> Colin >> From owner-sip-outgoing@lists.research.bell-labs.com Sun Mar 5 17:13:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11778 for ; Sun, 5 Mar 2000 17:13:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 236DC52DD; Sun, 5 Mar 2000 17:11:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 938D952DF; Sun, 5 Mar 2000 17:11:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C492C52DD for ; Sun, 5 Mar 2000 17:11:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 5 17:09:46 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Sun Mar 5 17:07:12 EST 2000 Received: from dynamicsoft.com (1Cust58.tnt2.freehold.nj.da.uu.net [63.17.114.58]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA18704; Sun, 5 Mar 2000 17:09:41 -0500 (EST) Message-ID: <38C2DC68.973CB2F7@dynamicsoft.com> Date: Sun, 05 Mar 2000 17:15:04 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Menard List Account Cc: Henning Schulzrinne , "'sip@lists.research.bell-labs.com'" Subject: Re: INVITE with RTP RR's to a different address ... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit You can easily have both the RTP and RTCP go to one IP address, different than the SIP originator (media will go to the address listed in the SDP). However, there is no way to have the RTP and RTCP go to different addresses. -Jonathan R. Francois Menard List Account wrote: > > Is there a quick way to require the RTP RR's to go to a different IP > address than the originating party through a SIP INVITE ? > > -=Francois=- -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Sun Mar 5 17:23:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11824 for ; Sun, 5 Mar 2000 17:23:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0B63452DF; Sun, 5 Mar 2000 17:21:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 63DD352E0; Sun, 5 Mar 2000 17:21:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EA3B352DF for ; Sun, 5 Mar 2000 17:21:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 5 17:20:52 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Sun Mar 5 17:18:18 EST 2000 Received: from dynamicsoft.com (1Cust58.tnt2.freehold.nj.da.uu.net [63.17.114.58]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA18713; Sun, 5 Mar 2000 17:17:12 -0500 (EST) Message-ID: <38C2DE2B.ECDDFAEA@dynamicsoft.com> Date: Sun, 05 Mar 2000 17:22:35 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Manjunath Bangalore Cc: Shail Bhatnagar , sip@lists.research.bell-labs.com, Rajneesh Kumar , Neil Joffe Subject: Re: SIP 1xx Response... References: <200003032337.PAA18282@zipper.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Manjunath Bangalore wrote: > > > 100 would be consumed by the stateful proxy - so there is no point > > including it in the "100 Trying" response. > > > > Assuming there is no proxy in the scenario under consideration > (eg: GW <---> GW), I wanted to know if it is acceptable to do that... Big assumption, and it will be wrong in any interesting case. I would highly recommend against doing this. Odds are good that most UAs won't look at the contents of a 100 response, since its hop by hop. If you want some kind of early media, why not use the 183 message, designed for this purpose? -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Sun Mar 5 18:03:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12102 for ; Sun, 5 Mar 2000 18:03:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 84F4452DE; Sun, 5 Mar 2000 18:01:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D69A452E2; Sun, 5 Mar 2000 18:01:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6537D52DE for ; Sun, 5 Mar 2000 18:01:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 5 18:00:10 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Sun Mar 5 17:57:37 EST 2000 Received: from dynamicsoft.com (1Cust58.tnt2.freehold.nj.da.uu.net [63.17.114.58]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA18774; Sun, 5 Mar 2000 18:00:15 -0500 (EST) Message-ID: <38C2E842.A80127C3@dynamicsoft.com> Date: Sun, 05 Mar 2000 18:05:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sudipto Mukherjee Cc: archow@hss.hns.com, schulzrinne@cs.columbia.edu, sip@lists.research.bell-labs.com Subject: Re: Tag in 200 OK response for CANCEL References: <65256897.0014BB33.00@sampark.hss.hns.com> <38BFD5DD.3472F7C6@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sudipto Mukherjee wrote: > > > This scenario will happen in a normal case (when UAS initiates > disconnect) > and not necessarily when the sending side is broken. > > UAC UAS > INV From:UAC, To:UAS > ------------------------------> > 200 OK (From:UAC, To:UAS;tag=123 > <------------------------------ > ACK (From:UAC, To:UAS;tag=123) > --------------------------------> > > > > BYE(From:UAS;tag=123, To:UAC) > <------------------------------- > 200 OK (From:UAS;tag=123, To:UAC) > --------------------------------> > > Now if the Called Party disconnects, the BYE generated by the > UAS will *not* have a Tag in the To header. The From header has the > tag, in this case. From and To are flipped when the request is > generated by UAS. The same goes for a re-INVITE. > > As I understood from Jonathan's reply, the From and To (including > the tags) are established during call setup phase and should remain > the same for subsequent transactions within the same call. Hence there > is no need for the UAC to add a tag in the BYE 200 OK response. Exactly correct. I believe this to be the simpler case, since otherwise, call leg identifiers can change post call setup. This can be handled, but it seems more complex that specifying not to insert the tag in responses to transactions after the call is established. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Sun Mar 5 18:41:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12271 for ; Sun, 5 Mar 2000 18:41:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C7AD652E0; Sun, 5 Mar 2000 18:39:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 45EF052E3; Sun, 5 Mar 2000 18:39:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 97E9652E0 for ; Sun, 5 Mar 2000 18:39:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 5 18:37:54 EST 2000 Received: from mw.3com.com ([149.112.20.3]) by dusty; Sun Mar 5 18:35:20 EST 2000 Received: from mwgate01.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id RAA01074; Sun, 5 Mar 2000 17:34:27 -0600 (CST) Received: from 3leet.sfour.com ([149.112.117.203]) by mwgate01.mw.3com.com (Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) with SMTP id 86256899.0081690A; Sun, 5 Mar 2000 17:33:30 -0600 Received: (from vektor@localhost) by 3leet.sfour.com (8.9.3/8.9.3/Debian 8.9.3-6) id RAA06117; Sun, 5 Mar 2000 17:34:12 -0600 Date: Sun, 5 Mar 2000 17:34:12 -0600 From: Billy Biggs To: sip@lists.research.bell-labs.com Cc: nat@livingston.com Subject: SIP NAT Draft and Linux Masquerading Module Message-ID: <20000305173412.A5870@mw.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, I have just submitted a draft describing an Application Level Gateway (ALG) for simple SIP sessions to allow them to pass transparently through a NAT device. A copy of the submitted draft is available here: http://www.sip-happens.com/masquerade/draft-biggs-sip-nat-00.txt We are also releasing the source code for a Linux IP Masquerading module for SIP. This allows a Linux NAT setup to transparently proxy SIP sessions, and is a sample implementation of the ALG described in the above draft. The source for this module and more information about what it supports is available at: http://www.sip-happens.com/masquerade/ We hope that by providing the draft and sample implementation that they can help promote the addition of simple SIP session support to other NAT and Firewall products. Thanks, -- Billy_Biggs@mw.3com.com From owner-sip-outgoing@lists.research.bell-labs.com Sun Mar 5 22:44:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16016 for ; Sun, 5 Mar 2000 22:44:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D8F0652E3; Sun, 5 Mar 2000 22:41:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 649FD52E4; Sun, 5 Mar 2000 22:41:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 7D3CF52E3 for ; Sun, 5 Mar 2000 22:41:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sun Mar 5 22:40:45 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Sun Mar 5 22:38:10 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id JAA28172 for ; Mon, 6 Mar 2000 09:38:53 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525689A.00144C46 ; Mon, 6 Mar 2000 09:11:42 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: sip@lists.research.bell-labs.com Message-ID: <6525689A.00144A7E.00@sampark.hss.hns.com> Date: Mon, 6 Mar 2000 09:11:37 +0530 Subject: Clarification on Request-URI not matching receving server Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk (wrt bis draft dated Aug 99, Exp: Feb 2000) Hi, Please refer to Page 29, Sec 4.3 Req-URI IIt mentions that if the host part of Req-URI does not match that of the current host, it should ether proxy it fwd or return 404. However, the above does not hold true in the case Max-Fwd decreases to 0 and the req is INVITE or OPTIONS, in whichcase the receiving proxy should act as the intended node. Shouldn't this exclusion be added to the global statement above ? Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems From owner-sip-outgoing@lists.research.bell-labs.com Sun Mar 5 23:07:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16269 for ; Sun, 5 Mar 2000 23:07:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7B53B52E4; Sun, 5 Mar 2000 23:05:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F0FCF52E5; Sun, 5 Mar 2000 23:05:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5900F52E4 for ; Sun, 5 Mar 2000 23:05:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 5 23:04:32 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Sun Mar 5 23:01:58 EST 2000 Received: from dynamicsoft.com (1Cust58.tnt2.freehold.nj.da.uu.net [63.17.114.58]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA18915; Sun, 5 Mar 2000 23:04:40 -0500 (EST) Message-ID: <38C32F99.1CA0D26E@dynamicsoft.com> Date: Sun, 05 Mar 2000 23:10:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: sip@lists.research.bell-labs.com Subject: Re: Clarification on Request-URI not matching receving server References: <6525689A.00144A7E.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit archow@hss.hns.com wrote: > > (wrt bis draft dated Aug 99, Exp: Feb 2000) > > Hi, > > Please refer to Page 29, Sec 4.3 Req-URI > > IIt mentions that if the host part of Req-URI does not match that of the > current host, it should ether proxy it fwd or return 404. > > However, the above does not hold true in the case Max-Fwd decreases to 0 > and the req is INVITE or OPTIONS, in whichcase the > receiving proxy should act as the intended node. Shouldn't this exclusion > be added to the global statement above ? Well, there are lots of other error conditions which might cause the request not to be forwarded - Via loops, malformed requests, incorrect content-lengths, missing To or From, etc. I don't think we need to mention these exceptional cases within the text of every normal case processing rule. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 00:01:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17062 for ; Mon, 6 Mar 2000 00:01:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 19BE952E2; Sun, 5 Mar 2000 23:59:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7EE6952E6; Sun, 5 Mar 2000 23:59:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 89D7C52E2 for ; Sun, 5 Mar 2000 23:59:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 5 23:58:36 EST 2000 Received: from mail.huawei.com.cn ([202.96.135.132]) by dusty; Sun Mar 5 23:56:02 EST 2000 Received: from y13638 ([10.108.22.162]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA28398 for ; Mon, 6 Mar 2000 12:58:28 +0800 Message-ID: <004001bf8728$5d24d600$a2166c0a@y13638.huawei.com.cn> Reply-To: "yinshaohua" From: "yinshaohua" To: Subject: Two questions Date: Mon, 6 Mar 2000 12:56:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I have two questions about RFC2543,: A. In RFC2543bis, there has " A BYE request from either called or calling party terminates any pending INVITE, but the INVITE request transaction must be completed with a final response". is it necessary to send response to INVITE and BYE simultaneously ? If necessary, we can define single response that indicate the above case. so it is simpler. B. A forking proxy can forward a request to different UAS, then UAS add Tag to TO header field of backward response in order to distinguish the Call Leg. So how can we guarantee the Tag added by different UAS single ? In other words, different UAS may add the same Tag, so we can not distinguish the response from them. have there any rational explanation ? Regards! Shaohua Yin From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 00:38:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17290 for ; Mon, 6 Mar 2000 00:38:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E2CF552E6; Mon, 6 Mar 2000 00:34:15 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0C06952E7; Mon, 6 Mar 2000 00:34:11 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6225752E6 for ; Mon, 6 Mar 2000 00:33:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 6 00:32:02 EST 2000 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by dusty; Mon Mar 6 00:29:28 EST 2000 Received: from drawbridge.ascend.com ([198.4.92.1]) by dirty; Mon Mar 6 00:30:29 EST 2000 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id VAA20285; Sun, 5 Mar 2000 21:20:40 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 6 Mar 2000 05:27:04 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id VAA14378; Sun, 5 Mar 2000 21:27:03 -0800 (PST) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000305212417.00b3b620@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 05 Mar 2000 21:27:14 -0800 To: Billy Biggs From: Matt Holdrege Subject: Re: (NAT) SIP NAT Draft and Linux Masquerading Module Cc: sip@lists.research.bell-labs.com, nat@livingston.com In-Reply-To: <20000305173412.A5870@mw.3com.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Thanks for the good work. FYI to you and all SIP'sters, please review the text on SIP in draft-ietf-nat-protocol-complications-02.txt which should appear in the I-D directory soon or at http://www.ietf.org/html.charters/nat-charter.html The current text is a bit old and I'm not sure how accurate it is, so a review would be appreciated by all who care about SIP and NAT. At 05:34 PM 3/5/00 -0600, Billy Biggs wrote: >Hi, > > I have just submitted a draft describing an Application Level Gateway (ALG) >for simple SIP sessions to allow them to pass transparently through a NAT >device. A copy of the submitted draft is available here: > > http://www.sip-happens.com/masquerade/draft-biggs-sip-nat-00.txt > > We are also releasing the source code for a Linux IP Masquerading > module for >SIP. This allows a Linux NAT setup to transparently proxy SIP sessions, >and is >a sample implementation of the ALG described in the above draft. The source >for this module and more information about what it supports is available at: > > http://www.sip-happens.com/masquerade/ > > We hope that by providing the draft and sample implementation that they can >help promote the addition of simple SIP session support to other NAT and >Firewall products. > > Thanks, >-- >Billy_Biggs@mw.3com.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe nat' in the body of the message. From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 01:14:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18246 for ; Mon, 6 Mar 2000 01:14:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 60C7652E5; Mon, 6 Mar 2000 01:11:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C850252E8; Mon, 6 Mar 2000 01:11:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id D730652E5 for ; Mon, 6 Mar 2000 01:11:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 6 01:10:45 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Mon Mar 6 01:08:12 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust185.tnt1.long-branch.nj.da.uu.net [63.25.225.185]) id QQifho21162; Mon, 6 Mar 2000 06:10:20 GMT Message-ID: <38C34C2B.5A1AC76A@dynamicsoft.com> Date: Mon, 06 Mar 2000 01:11:55 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: yinshaohua , sip@lists.research.bell-labs.com Subject: Re: Two questions References: <004001bf8728$5d24d600$a2166c0a@y13638.huawei.com.cn> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit yinshaohua wrote: > > A. In RFC2543bis, there has " A BYE request from either called or > calling party terminates any pending INVITE, but the INVITE request > transaction must be completed with a final response". is it necessary to > send response to INVITE and BYE simultaneously ? If necessary, we can define > single response that indicate the above case. so it is simpler. It is simpler to have all transactions complete in a consistent manner than to create special cases by making the behavior dependent on consecutive transactions. Besides, BYE/CANCEL and a response to INVITE may cross on the wire so the UAC should still be prepared to send an ACK should a final response be received. > So how can we guarantee the Tag added by different UAS single ? In > other words, different UAS may add the same Tag, so we can not distinguish > the response from them. The draft says that "the tag value MUST be globally unique". You are free to use any algorithm that ensures such uniqueness. RFC2543 suggests that you use UUID for tags; a copy of UUID/GUID draft can be found at http://www.ics.uci.edu/pub/ietf/webdav/uuid-guid/draft-leach-uuids-guids-01.txt. Note that the draft itself has expired and is no longer maintained in IETF archives; the same algorithm is described in an appendix to ISO-11578 (ISO RPC standard), the only tangible difference is the extra information in the IETF draft on how to generate GUIDs without embedding hardware ethernet addresses. --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 07:02:33 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02822 for ; Mon, 6 Mar 2000 07:02:33 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 291AD52C8; Mon, 6 Mar 2000 06:59:26 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 98FAD52D6; Mon, 6 Mar 2000 06:59:25 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B8F8052C8 for ; Mon, 6 Mar 2000 06:59:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 6 06:57:05 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Mon Mar 6 06:54:31 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02384; Mon, 6 Mar 2000 06:57:02 -0500 (EST) Message-Id: <200003061157.GAA02384@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-camarillo-sip-isup-bcp-00.txt Date: Mon, 06 Mar 2000 06:56:58 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Best Current Practice for ISUP to SIP mapping Author(s) : G. Camarillo, A. Roach Filename : draft-camarillo-sip-isup-bcp-00.txt Pages : 50 Date : 03-Mar-00 This document describes a way to perform the mapping between two signalling protocols: SIP and ISUP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-camarillo-sip-isup-bcp-00.txt 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-camarillo-sip-isup-bcp-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-camarillo-sip-isup-bcp-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: <20000303120018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-camarillo-sip-isup-bcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-camarillo-sip-isup-bcp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000303120018.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 10:32:11 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09955 for ; Mon, 6 Mar 2000 10:32:10 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1EE5552B6; Mon, 6 Mar 2000 10:29:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 878EB52C4; Mon, 6 Mar 2000 10:29:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id ABF9452B6 for ; Mon, 6 Mar 2000 10:29:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 6 10:28:16 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Mon Mar 6 10:25:40 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id VAA17889; Mon, 6 Mar 2000 21:24:40 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525689A.003DE97C ; Mon, 6 Mar 2000 16:46:14 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: archow@hss.hns.com, sip@lists.research.bell-labs.com Message-ID: <6525689A.001B97DF.00@sampark.hss.hns.com> Date: Mon, 6 Mar 2000 10:31:23 +0530 Subject: Re: Clarification on Request-URI not matching receving server Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Actually this is not an error condition . Its a valid conditon where a SIP Request is replied to even though its not directly meant for it . In this case, there is no error in the message, but a special clause that results in a server acting on behalf of another - not rejecting it. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jonathan Rosenberg on 03/06/2000 09:40:01 AM To: archow cc: sip@lists.research.bell-labs.com Subject: Re: Clarification on Request-URI not matching receving server archow@hss.hns.com wrote: > > (wrt bis draft dated Aug 99, Exp: Feb 2000) > > Hi, > > Please refer to Page 29, Sec 4.3 Req-URI > > IIt mentions that if the host part of Req-URI does not match that of the > current host, it should ether proxy it fwd or return 404. > > However, the above does not hold true in the case Max-Fwd decreases to 0 > and the req is INVITE or OPTIONS, in whichcase the > receiving proxy should act as the intended node. Shouldn't this exclusion > be added to the global statement above ? Well, there are lots of other error conditions which might cause the request not to be forwarded - Via loops, malformed requests, incorrect content-lengths, missing To or From, etc. I don't think we need to mention these exceptional cases within the text of every normal case processing rule. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 11:28:21 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13201 for ; Mon, 6 Mar 2000 11:28:19 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DD9F952BB; Mon, 6 Mar 2000 11:25:35 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 630A152C8; Mon, 6 Mar 2000 11:25:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3A2EE52BB for ; Mon, 6 Mar 2000 11:25:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 6 11:23:47 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 6 11:21:13 EST 2000 Received: from dynamicsoft.com (1Cust93.tnt2.freehold.nj.da.uu.net [63.17.114.93]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA20272 for ; Mon, 6 Mar 2000 11:23:55 -0500 (EST) Message-ID: <38C3DCE1.254D3F52@dynamicsoft.com> Date: Mon, 06 Mar 2000 11:29:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Agenda items for Adelaide Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, If you want a slot at the Adelaide meeting of the SIP WG, please contact one of the chairs asap. We expect to have lots of requests, and so our plan is to prioritize them as follows: 1. Top priority are requests that related to agreed upon work items of the group, particularly discussions of open issues. 2. Second priority are requests to talk about work in a draft which has been submitted to IETF, but which is not currently a work item of the SIP WG. 3. Last priority are requests to talk on subjects with no accompanying draft, and which are not work items. We expect most of these requests will not be granted because of volume in the above two categories. Remember, the Internet Drafts deadline is this Friday, 5pm EST. Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 11:32:47 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13495 for ; Mon, 6 Mar 2000 11:32:41 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 25F6052D4; Mon, 6 Mar 2000 11:29:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8AC1B52C8; Mon, 6 Mar 2000 11:29:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 81D2052D4 for ; Mon, 6 Mar 2000 11:29:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 6 11:27:23 EST 2000 Received: from dwillis.wcomnet.com ([166.35.230.139]) by dusty; Mon Mar 6 11:24:50 EST 2000 Received: from dwillispc8 ([166.44.162.170]) by dwillis.wcomnet.com (8.9.3/8.9.3) with SMTP id KAA08008; Mon, 6 Mar 2000 10:27:18 -0600 From: "Dean Willis" To: , Subject: RE: Where can I find the draft Sip BCP Date: Mon, 6 Mar 2000 10:26:30 -0600 Message-ID: <005601bf8788$ba814800$aaa22ca6@wcomnet.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 In-reply-to: <88256897.005E4FB4.00@hqoutbound.ops.3com.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I think I have the various SIP-T documents indexed at: http://www.softarmor.com/sipwg/teams/sipt/index.html You SIP-T folks check and tell me what I'm missing, please! -- Dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of > Anoop_Tripathi@3com.com > Sent: Friday, March 03, 2000 11:12 AM > To: sip@lists.research.bell-labs.com > Subject: Where can I find the draft Sip BCP > > > > > > Hi, > > I was looking for the SIP : Best Current Practices draft ? Could > someone point > me to it. > > > Thanks, > > Anoop > > > From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 15:46:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28002 for ; Mon, 6 Mar 2000 15:46:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EDD5852B6; Mon, 6 Mar 2000 15:43:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6C66752C4; Mon, 6 Mar 2000 15:43:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 1150F52B6 for ; Mon, 6 Mar 2000 15:43:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 6 15:42:53 EST 2000 Received: from ns.fmmo.ca ([207.253.160.156]) by dusty; Mon Mar 6 15:40:19 EST 2000 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id PAA11741; Mon, 6 Mar 2000 15:46:33 -0500 Date: Mon, 6 Mar 2000 15:46:32 -0500 (EST) From: Francois Menard List Account To: Jonathan Rosenberg Cc: Henning Schulzrinne , "'sip@lists.research.bell-labs.com'" Subject: Re: INVITE with RTP RR's to a different address ... In-Reply-To: <38C2DC68.973CB2F7@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Does anybody oppose the idea of designing a specific way to do this ... I know that RTCP has to be managed end-to-end, but there are good instances where capturing the RTCP feedback in a central repository is better than doing Netflow analysis ... -=Francois=- On Sun, 5 Mar 2000, Jonathan Rosenberg wrote: > You can easily have both the RTP and RTCP go to one IP address, > different than the SIP originator (media will go to the address listed > in the SDP). However, there is no way to have the RTP and RTCP go to > different addresses. > > -Jonathan R. > > Francois Menard List Account wrote: > > > > Is there a quick way to require the RTP RR's to go to a different IP > > address than the originating party through a SIP INVITE ? > > > > -=Francois=- > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 17:36:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16878 for ; Mon, 6 Mar 2000 17:35:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E8C0852B6; Mon, 6 Mar 2000 17:33:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6C56952BB; Mon, 6 Mar 2000 17:33:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5F12352B6 for ; Mon, 6 Mar 2000 17:33:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 6 17:32:54 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 6 17:30:20 EST 2000 Received: from dynamicsoft.com (1Cust93.tnt2.freehold.nj.da.uu.net [63.17.114.93]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA21963 for ; Mon, 6 Mar 2000 17:33:02 -0500 (EST) Message-ID: <38C43361.1E25855A@dynamicsoft.com> Date: Mon, 06 Mar 2000 17:38:25 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Another task force formed Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, We had discussed this in the past, but we have finally formed a task force to look at SIP for "home phone line service", also known as single line extension. The immediate goal of this group is to scope out what the service should look like, and then go about defining any SIP extensions needed to support it. Those folks who sent me email initially asking to be involved have been added to the team. If you are interested, but haven't sent me mail yet about this, please feel free to do so. Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 17:57:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21396 for ; Mon, 6 Mar 2000 17:57:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 30D3F52AB; Mon, 6 Mar 2000 17:55:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9B51A52C4; Mon, 6 Mar 2000 17:55:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A953E52AB for ; Mon, 6 Mar 2000 17:55:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 6 17:53:49 EST 2000 Received: from ids2.idsonline.com ([205.177.236.32]) by dusty; Mon Mar 6 17:51:16 EST 2000 Received: from 21rst-century.com (laurel-md-218.idsonline.com [209.8.42.218]) by ids2.idsonline.com (8.9.1/8.6.9) with ESMTP id TAA06348; Mon, 6 Mar 2000 19:04:20 -0500 Message-ID: <38C4367B.B7274C28@21rst-century.com> Date: Mon, 06 Mar 2000 17:51:38 -0500 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Matt Holdrege Cc: Billy Biggs , sip@lists.research.bell-labs.com, nat@livingston.com Subject: Re: (NAT) SIP NAT Draft and Linux Masquerading Module References: <4.2.2.20000305212417.00b3b620@porky> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Matt Holdrege wrote: > Thanks for the good work. FYI to you and all SIP'sters, please review the > text on SIP in draft-ietf-nat-protocol-complications-02.txt which should > appear in the I-D directory soon or at > http://www.ietf.org/html.charters/nat-charter.html > > The current text is a bit old and I'm not sure how accurate it is, so a > review would be appreciated by all who care about SIP and NAT. > Note : The charter references http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-01.txt which will get you a 404: File not found. http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-02.txt gets the March 2000 draft. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, LLC P.O. Box 99 Clifton, Virginia 20124 Phone : 703-803-8141 Fax : 703-222-3250 e-mail : tme@21rst-century.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 18:20:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25938 for ; Mon, 6 Mar 2000 18:19:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B53C152C4; Mon, 6 Mar 2000 18:17:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 36DED52C8; Mon, 6 Mar 2000 18:17:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7A9A252C4 for ; Mon, 6 Mar 2000 18:17:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 6 18:17:03 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Mon Mar 6 18:14:30 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id SAA27652; Mon, 6 Mar 2000 18:16:59 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38C4691B.AF529FE5@vovida.com> Date: Mon, 06 Mar 2000 18:27:39 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Subject: SIP INFO method Content-Type: multipart/alternative; boundary="------------7E41D5A1536262C5A18CB3BB" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------7E41D5A1536262C5A18CB3BB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: Is some one aware of the current status of this draft? Also, a question on the current draft: It is said that the INFO msg follows the protocol rules of the BYe msg. so, does this imply that a InFo msg should be sent from the caller after the 200 OK is received, and from the callee after the ACKis received? Thanks much! -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------7E41D5A1536262C5A18CB3BB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi:

Is some one aware of the current status of this draft?

Also, a question on the current draft:
It is said that the INFO msg follows the protocol rules of the BYe msg. so, does this imply that  a InFo msg should be sent from the caller after the 200 OK is received, and from the callee after the ACKis received?

Thanks much! 

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374
  --------------7E41D5A1536262C5A18CB3BB-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 21:23:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27792 for ; Mon, 6 Mar 2000 21:23:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1D46752B6; Mon, 6 Mar 2000 21:21:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8817A52BB; Mon, 6 Mar 2000 21:21:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6A85752B6 for ; Mon, 6 Mar 2000 21:21:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 6 21:19:23 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 6 21:16:50 EST 2000 Received: from dynamicsoft.com (1Cust93.tnt2.freehold.nj.da.uu.net [63.17.114.93]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA22668; Mon, 6 Mar 2000 21:19:30 -0500 (EST) Message-ID: <38C46873.AFE69768@dynamicsoft.com> Date: Mon, 06 Mar 2000 21:24:51 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sunitha Kumar Cc: SIPbell-labs Subject: Re: SIP INFO method References: <38C4691B.AF529FE5@vovida.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sunitha Kumar wrote: > > Hi: > > Is some one aware of the current status of this draft? This draft is under consideration by IESG for proposed standard. > > Also, a question on the current draft: > It is said that the INFO msg follows the protocol rules of the BYe > msg. so, does this imply that a InFo msg should be sent from the > caller after the 200 OK is received, and from the callee after the > ACKis received? Huh? Of course not. By follow the rules, it means retransmission rules, tag handling, route processing, etc. This is stated quite explicitly in the document: > 2.4 Behavior of SIP User Agents > > Unless stated otherwise, the protocol rules for the INFO request > governing the usage of tags, Route and Record-Route, > retransmission and reliability, CSeq incrementing and message > formatting follow those in [1] as defined for the BYE request. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 6 22:36:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13208 for ; Mon, 6 Mar 2000 22:36:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4F24A52AB; Mon, 6 Mar 2000 22:33:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BF13252C4; Mon, 6 Mar 2000 22:33:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7E9E852AB for ; Mon, 6 Mar 2000 22:33:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 6 22:31:54 EST 2000 Received: from dwarpal.wipsys.soft.net ([164.164.127.8]) by dusty; Mon Mar 6 22:29:20 EST 2000 Received: from ace.wipsys.soft.net (ace.wipsys.soft.net [164.164.29.18]) by dwarpal.wipsys.soft.net (8.9.3/8.9.3) with ESMTP id JAA26189 for ; Tue, 7 Mar 2000 09:04:01 +0530 (IST) Received: from hemant ([164.164.29.109]) by ace.wipsys.soft.net (Netscape Messaging Server 3.6) with SMTP id AAA2976; Tue, 7 Mar 2000 08:59:03 +0530 Message-ID: <004601bf87e6$34d6e670$6d1da4a4@wipsys.soft.net> From: "HEMANT AGRAWAL" To: , Cc: Subject: Activation of Call Forwarding in Proxy Server Date: Tue, 7 Mar 2000 09:05:35 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi , In Ref. to Sec. 2.5 "Call Forwarding Unconditional" etc of "draft-sparks-sip-service-examples-00". Can anybody tell me how to tell the proxy server "calls to me at my registered URL should be forwarded to another URL." Is there any feature activation procedures in SIP (In H.323, H.450.3 have procedures for activating CFU etc. features in Gatekeeper) Regards, Hemant _______________________________________________________ Hemant Agrawal Tel:(Off.) 91-80-5539134 ext. 407 COE - Voice Over IP (Res.) 91-80-3499383 Wipro Technologies - Telecom Solutions. Email: hemant.agrawal@wipro.com " Govindam adi-purusam tam aham bhajami" From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 00:56:29 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08709 for ; Tue, 7 Mar 2000 00:56:29 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1EAD952AB; Tue, 7 Mar 2000 00:53:47 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7996D52BB; Tue, 7 Mar 2000 00:53:46 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2695252BB for ; Mon, 6 Mar 2000 10:45:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 6 10:43:22 EST 2000 Received: from fire.integralaccess.com ([63.160.25.239]) by dusty; Mon Mar 6 10:40:49 EST 2000 Received: from akankkunen [192.168.1.124] by fire.integralaccess.com (SMTPD32-6.00) id A265B6011A; Mon, 06 Mar 2000 10:44:37 -0500 From: "Antti Kankkunen" To: Date: Mon, 6 Mar 2000 10:45:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit FYI. (Please note also that there is going to be a VoMPLS BOF in Adelaide.) >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-kankkunen-vompls-fw-00.txt >Date: Thu, 02 Mar 2000 10:32:20 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Voice over MPLS Framework > Author(s) : A. Kankkunen, G. Ash, J. Hopkins, > B. Rosen, D. Stacey, A. Yelundur, L. Berger > Filename : draft-kankkunen-vompls-fw-00.txt > Pages : 51 > Date : 01-Mar-00 > >This document provides a Framework for using MPLS as the >underlying technology for transporting IP based public voice >services. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kankkunen-vompls-fw-00.txt > >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-kankkunen-vompls-fw-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-kankkunen-vompls-fw-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. >Content-Type: text/plain >Content-ID: <20000301084456.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kankkunen-vompls-fw-00.txt > > Best regards, Antti K. ------------------- Antti Kankkunen Integral Access Inc. 6 Omni Way Chelmsford, MA 01824 Phone: +1 978 256 8833 x 232 Mobile: +1 617 513 2172 Fax: +1 978 256 8077 e-mail: anttik@integralaccess.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 02:12:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06686 for ; Tue, 7 Mar 2000 02:12:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AE1BA52B6; Tue, 7 Mar 2000 02:09:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2793752BB; Tue, 7 Mar 2000 02:09:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 120F152B6 for ; Tue, 7 Mar 2000 02:09:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 7 02:07:13 EST 2000 Received: from commsun.its.csiro.au ([152.83.8.2]) by dusty; Tue Mar 7 02:04:39 EST 2000 Received: from its.csiro.au (erinnyes-mi.cbr.its.csiro.au [152.83.10.102]) by commsun.its.csiro.au (8.9.3/8.9.3) with ESMTP id SAA01724; Tue, 7 Mar 2000 18:06:48 +1100 (EST) Message-ID: <38C4A986.23B158A2@its.csiro.au> Date: Tue, 07 Mar 2000 18:02:30 +1100 From: Stephen Kingham X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com, apl-l Subject: Re: Another task force formed References: <38C43361.1E25855A@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jonathan, My name is Stephen Kingham and I have been working as the Engineer Responsible and over all Project Manager of a large VoIP project in Australia. Phase one of the project sees it carrying about 3,500 connected calls per working day and will grow by 10 or 40 time as each Australian University hooks on. The connected calls are made from users on PABXs to other PABXs, and into the Public Telephone Network without the users even knowing it is going over IP. Only recently have we considered involvement in the IETF working groups to feed back what we have learnt back into the standards. Some of the work in the QoS negotiation is of particular interest, particulary to ensure _Reliability_ is included as well as the bandwidth allocation. Anyway we are now gearing up for PABXless campuses and would like to see if we can contribute to the SIP for "home phone line service". I will be at the IETF and hope to learn more about the working group then and how we might be able to be involved. Regards Stephen Kingham Jonathan Rosenberg wrote: > Folks, > > We had discussed this in the past, but we have finally formed a task > force to look at SIP for "home phone line service", also known as single > line extension. The immediate goal of this group is to scope out what > the service should look like, and then go about defining any SIP > extensions needed to support it. > > Those folks who sent me email initially asking to be involved have been > added to the team. If you are interested, but haven't sent me mail yet > about this, please feel free to do so. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- Stephen Kingham, MIT, BSc, E&C Cert Project Manager and Consulting Engineer mailto:Stephen.Kingham@its.csiro.au Telephone +61 2 6276 6223 (office) +61 419 417 471 (mobile) Voice over IP Project for The Australian Acedemic Research Network (AARNet) and Commonwealth Scientific and Industrial Research Organisation (CSIRO) http://www.aarnet.edu.au/projects/voice and http://www.csiro.au Have a nice day. From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 05:46:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20894 for ; Tue, 7 Mar 2000 05:46:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 394D452BB; Tue, 7 Mar 2000 05:43:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AC07B52C4; Tue, 7 Mar 2000 05:43:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9CC4252BB for ; Tue, 7 Mar 2000 05:43:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 05:41:50 EST 2000 Received: from mail.siol.net ([193.189.160.10]) by dusty; Tue Mar 7 05:39:16 EST 2000 Received: from bhartpuri ([212.30.66.148]) by mail.siol.net (InterMail vK.4.02.00.00 201-232-116 license e0fb2c7d5b0eb8987a602e826035ffb5) with SMTP id <20000307104146.PCR19222.mail@bhartpuri> for ; Tue, 7 Mar 2000 11:41:46 +0100 Message-ID: <004401bf8821$f20d7610$0dca02c1@bhartpuri> From: "Bor Prihavec" To: "SIP Mailing List" References: <38C4691B.AF529FE5@vovida.com> Subject: Call center Date: Tue, 7 Mar 2000 11:43:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01BF882A.52BBB320" 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 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0041_01BF882A.52BBB320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi everyone, I am l looking for SIP based products (Telephony gateways, SIP Servers, = SIP User Agents, ...). available on market now or in a short time which = would allow me to build a VoIP based Call Center. So far I am aware of DynamicSoft, Vovida networks, Mediatrix and Object = Software.=20 I also need an ANSI C implementation of SIP stack / SIP User Agent to = use it on our DSP platform. Any hint is most welcome. Thanks in advance! Bor Prihavec ----------------------- Ultra d.o.o. Brnciceva 31 1000 Ljubljana Slovenia, Europe tel: + 386 61 161 5800 fax: + 386 61 161 5805 Bor.Prihavec@ultra.si ------=_NextPart_000_0041_01BF882A.52BBB320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi everyone,
 
I am l looking for SIP based products = (Telephony=20 gateways, SIP Servers, SIP User Agents, ...). available on market now or = in a=20 short time which would allow me to build a VoIP based Call = Center.
So far I am aware of DynamicSoft, = Vovida networks,=20 Mediatrix and Object Software.
 
I also need an ANSI C implementation of = SIP stack /=20 SIP User Agent to use it on our DSP platform.
 
Any hint is most = welcome.
Thanks in advance!
 
Bor Prihavec
 
-----------------------
Ultra d.o.o.
Brnciceva 31
1000=20 Ljubljana
Slovenia, Europe
tel: + 386 61 161 5800
fax: + 386 61 = 161=20 5805
Bor.Prihavec@ultra.si

------=_NextPart_000_0041_01BF882A.52BBB320-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 06:35:35 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00896 for ; Tue, 7 Mar 2000 06:35:35 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C897152C4; Tue, 7 Mar 2000 06:31:38 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 336A952D5; Tue, 7 Mar 2000 06:31:38 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D7D5152C4 for ; Tue, 7 Mar 2000 06:31:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 06:29:31 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Tue Mar 7 06:26:57 EST 2000 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id MAA20684; Tue, 7 Mar 2000 12:29:26 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.75.22]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA10378; Tue, 7 Mar 2000 13:29:23 +0200 (EET) Message-ID: <38C4E84D.4560419F@lmf.ericsson.se> Date: Tue, 07 Mar 2000 13:30:21 +0200 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mmusic , sip Subject: Sendonly in SDP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, User A wants to establish a session with user B. They will have bi directional audio. A wants to send video to B, but A does not want to receive video from B. A will add a parameter "a=sendonly" to its SDP. Since A does not want to receive, A does not have to provide any local port number. Is it correct to set the port number to 0?? m=video 0 RTP/AVP 31 a=sendonly Thanks, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 06:38:23 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01597 for ; Tue, 7 Mar 2000 06:38:23 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id ED3DB52D6; Tue, 7 Mar 2000 06:31:44 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E4F7552C8; Tue, 7 Mar 2000 06:31:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3F28752C8 for ; Tue, 7 Mar 2000 06:31:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 06:30:20 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Tue Mar 7 06:27:46 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29547; Tue, 7 Mar 2000 06:30:17 -0500 (EST) Message-Id: <200003071130.GAA29547@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sip-serverfeatures-02.txt Date: Tue, 07 Mar 2000 06:30:17 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --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 Supported Header Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-serverfeatures-02.txt Pages : 7 Date : 06-Mar-00 The Session Initiation Protocol (SIP) provides a mechanism that allows a client to request that a particular protocol extension be used to process the request. The server declines the request if it does not support the extension. However, there is currently no way for a server to determine which extensions are supported by the client. Knowing about client-supported extensions allows the server to tailor its response accordingly. Furthermore, SIP does not define a way for a client to query a server about the extensions it supports. This document defines a SIP extension that allows clients to indicate, in a request, the set of extensions supported. We also define a mechanism that allows clients, through an OPTIONS request, to determine the extensions supported by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-serverfeatures-02.txt 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-serverfeatures-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-serverfeatures-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000306120736.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-serverfeatures-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-serverfeatures-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000306120736.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 06:41:33 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02226 for ; Tue, 7 Mar 2000 06:41:32 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 99CA952C8; Tue, 7 Mar 2000 06:33:11 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D369D52D4; Tue, 7 Mar 2000 06:32:27 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C94B952D4 for ; Tue, 7 Mar 2000 06:31:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 06:30:15 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Tue Mar 7 06:27:42 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29529; Tue, 7 Mar 2000 06:30:13 -0500 (EST) Message-Id: <200003071130.GAA29529@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sip-call-flows-00.txt Date: Tue, 07 Mar 2000 06:30:12 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --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 Telephony Call Flow Examples Author(s) : A. Johnston, S. Donovan, R. Sparks,C. Cunningham, K. Summers, D. Willis, J. Rosenberg, H. Schulzrinne, Filename : draft-ietf-sip-call-flows-00.txt Pages : 268 Date : 06-Mar-00 This document gives examples of SIP (Session Initiation Protocol) call flows for IP telephony and service examples. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers, and Gateways to the PSTN (Public Switch Telephone Network). IP telephony scenarios include SIP Registration, SIP to SIP calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway via SIP. Call flow diagrams and message details are shown. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ANSI ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Telephony service examples illustrated with call flows include call hold, transfer, forwarding, screening, and Find-Me. Example SIP messages used for testing during SIP 'bakeoff' events include SIP 'torture test' messages, and messages with invalid parameters, methods, and tags. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-00.txt 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-call-flows-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-call-flows-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: <20000306120723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-call-flows-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-call-flows-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000306120723.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 06:44:14 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02729 for ; Tue, 7 Mar 2000 06:44:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 801DE52DB; Tue, 7 Mar 2000 06:39:44 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E200052DC; Tue, 7 Mar 2000 06:39:43 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D973752DB for ; Tue, 7 Mar 2000 06:39:10 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 06:38:49 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Tue Mar 7 06:36:16 EST 2000 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id MAA25259; Tue, 7 Mar 2000 12:38:41 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.75.22]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA10927; Tue, 7 Mar 2000 13:38:40 +0200 (EET) Message-ID: <38C4EA7A.EDD13A5A@lmf.ericsson.se> Date: Tue, 07 Mar 2000 13:39:38 +0200 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip , mmusic Subject: Mapping media streams Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, User A wants to establish a session with user B. A's SDP includes two video streams. m=video 1000 RTP/AVP 31 m=video 1002 RTP/AVP 31 User B wants to have just one video stream, so B sends back an SDP with just one video description: m=video 5000 RTP/AVP 31 How does A know which of its two video streams B wants to receive? Should in these situations (multiple streams containing media of the same type) the "i" attribute of SDP be used? (or it is not intended for this?) m=video 1000 RTP/AVP 31 i= front camera m=video 1002 RTP/AVP 31 i= panoramic camera This way B can choose wich one he wants to receive: m=video 5000 RTP/AVP 31 i= front camera This example may look pretty stupid, but when QoS preconditions are added to the SDP there are some useful scenarios for this. Thanks, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 07:20:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10474 for ; Tue, 7 Mar 2000 07:19:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4233352AB; Tue, 7 Mar 2000 07:17:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AA2EA52D5; Tue, 7 Mar 2000 07:17:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 94DF852AB for ; Tue, 7 Mar 2000 07:17:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 07:16:54 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Tue Mar 7 07:14:20 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id 5B8A2151C; Tue, 7 Mar 2000 04:16:51 -0800 (PST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA13985; Tue, 7 Mar 2000 12:16:49 GMT Message-ID: <38C4F349.E694991D@hplb.hpl.hp.com> Date: Tue, 07 Mar 2000 12:17:13 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: sip , mmusic Subject: Re: Mapping media streams References: <38C4EA7A.EDD13A5A@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > Hi, > > User A wants to establish a session with user B. A's SDP includes two > video streams. > > m=video 1000 RTP/AVP 31 > m=video 1002 RTP/AVP 31 > > User B wants to have just one video stream, so B sends back an SDP with > just one video description: > > m=video 5000 RTP/AVP 31 > > How does A know which of its two video streams B wants to receive? This is all described in appendix B of rfc 2543. The caller and callee align their media descriptions so that the nth media stream ("m=" line) in the caller's session description corresponds to the nth media stream in the callee's description. SDP bodies in 2xx responses to INVITEs must have the same number of m= lines as did the request, and in the same order, i.e. the n'th m= line of the response corresponds to the n'th line in the request. If the caller can't or doesn't want to establish a particular stream it must still have the m= line in the response: If caller and callee have no media formats in common for a particular stream, the callee MUST return a session description containing the particular "m=" line, but with the port number set to zero, and no payload types listed. In your example the callee might return m=video 5000 RTP/AVP 31 m=video 0 RTP/AVP Frankly, this method of referring to media streams isn't the most wonderful aspect of SIP. Once upon a time there was a thread on a specific issue relating to SDP media alignment: http://www-uk.hpl.hp.com/people/ak/confctrl/1999/msg00297.html > > Should in these situations (multiple streams containing media of the > same type) the "i" attribute of SDP be used? (or it is not intended for > this?) > > m=video 1000 RTP/AVP 31 > i= front camera > m=video 1002 RTP/AVP 31 > i= panoramic camera Something along these lines was actually proposed by Peter Peldan. The idea was to associate a UID with media streams and then use that to refer to them later, e.g. in the response to the initial INVITE and later, when renegotiating streams using re-INVITEs. IMHO this would be a big improvement on the present method of referring to streams by position in the initial INVITE. > > This way B can choose wich one he wants to receive: > > m=video 5000 RTP/AVP 31 > i= front camera > > This example may look pretty stupid, but when QoS preconditions are > added to the SDP there are some useful scenarios for this. > Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 07:56:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17725 for ; Tue, 7 Mar 2000 07:56:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 19E7352D4; Tue, 7 Mar 2000 07:53:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8C3C852DA; Tue, 7 Mar 2000 07:53:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8F2EF52D4 for ; Tue, 7 Mar 2000 07:53:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 07:51:57 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Tue Mar 7 07:49:21 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA08800; Tue, 7 Mar 2000 18:48:09 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525689B.00469D6D ; Tue, 7 Mar 2000 18:21:18 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Gonzalo Camarillo Cc: mmusic , sip Message-ID: <6525689B.00469488.00@sampark.hss.hns.com> Date: Tue, 7 Mar 2000 18:13:46 +0530 Subject: Re: Sendonly in SDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Referring appendix B.2 (bis draft) - for unicast transmission (which is what I guess you were asking) For receive-only and send-or-receive streams, the port number and address in the session description indicate where the media stream should be sent to by the recipient of the session description, either caller or callee. * For send-only streams, the address and port number have no significance and SHOULD be set to zero.* Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Gonzalo Camarillo on 03/07/2000 05:00:21 PM To: mmusic , sip cc: Subject: Sendonly in SDP Hi, User A wants to establish a session with user B. They will have bi directional audio. A wants to send video to B, but A does not want to receive video from B. A will add a parameter "a=sendonly" to its SDP. Since A does not want to receive, A does not have to provide any local port number. Is it correct to set the port number to 0?? m=video 0 RTP/AVP 31 a=sendonly Thanks, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 08:36:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27894 for ; Tue, 7 Mar 2000 08:35:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C5E9252DA; Tue, 7 Mar 2000 08:33:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3F6AC52DC; Tue, 7 Mar 2000 08:33:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5CC0D52DA for ; Tue, 7 Mar 2000 08:33:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 08:32:10 EST 2000 Received: from mail.mera.ru ([195.98.50.58]) by dusty; Tue Mar 7 08:29:36 EST 2000 Received: from abc (abc.mera.ru [195.98.57.251]) by mail.mera.ru (8.9.3/8.9.3) with SMTP id QAA02642; Tue, 7 Mar 2000 16:32:02 +0300 (MSK) Message-ID: <009e01bf883a$dff1cdf0$fb3962c3@mera.ru> From: "Alexei Prokofiev" To: "sip" Cc: , Subject: Several TCP connections for the same SIP transaction Date: Tue, 7 Mar 2000 16:41:42 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01BF8854.044F27B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_009B_01BF8854.044F27B0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, should a client UA accept replies of a transaction in case they are sent = by a server UA via several TCP connections different from the one used=20 to send the request of the transaction? Thanks a lot! ----------- Alexei Prokofiev, mailto:palx@null.net Software Engeneer, =20 Mera Labs.=20 ------=_NextPart_000_009B_01BF8854.044F27B0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi,
 
should a client UA accept = replies of a=20 transaction in case they are=20 sent 
by a server UA via several TCP = connections=20 different from the one used =
to send the request of the=20 transaction?
 
Thanks a lot!
 
-----------
Alexei=20 Prokofiev,        mailto:palx@null.net
Software Engeneer,    =
Mera Labs.
------=_NextPart_000_009B_01BF8854.044F27B0-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 09:22:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08087 for ; Tue, 7 Mar 2000 09:22:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 793A852D5; Tue, 7 Mar 2000 09:19:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E8E9F52DD; Tue, 7 Mar 2000 09:19:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 95C0E52D5 for ; Tue, 7 Mar 2000 09:19:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 09:18:04 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Tue Mar 7 09:15:29 EST 2000 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA29253; Tue, 7 Mar 2000 15:17:57 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.75.22]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA17985; Tue, 7 Mar 2000 16:17:54 +0200 (EET) Message-ID: <38C50FCB.89DBD8A3@lmf.ericsson.se> Date: Tue, 07 Mar 2000 16:18:51 +0200 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ak@hplb.hpl.hp.com Cc: sip@lists.research.bell-labs.com, confctrl@ISI.EDU, Peter.Peldan@ellemtel.se Subject: Re: Mapping media streams References: <38C4F349.E694991D@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hej Anders, Thanks for pointing out the URL with the previous discussion (I have included a mail from Peter Peldan below). What was the final result of the discussion? Since I have seen no changes to the spec I guess the media alignment is still done matching the nths "m" lines, right? What about if the callee wants to add a media stream to the session? The callee might want to send a new m line in the 200 OK. Should this be allowed? Comments? Thanks, Gonzalo ak@hplb.hpl.hp.com wrote: > > Gonzalo Camarillo wrote: > > > > Hi, > > > > User A wants to establish a session with user B. A's SDP includes two > > video streams. > > > > m=video 1000 RTP/AVP 31 > > m=video 1002 RTP/AVP 31 > > > > User B wants to have just one video stream, so B sends back an SDP with > > just one video description: > > > > m=video 5000 RTP/AVP 31 > > > > How does A know which of its two video streams B wants to receive? > > This is all described in appendix B of rfc 2543. > > The caller and callee align their media descriptions so that the nth > media stream ("m=" line) in the caller's session description > corresponds to the nth media stream in the callee's description. > > SDP bodies in 2xx responses to INVITEs must have the same number of m= > lines as did the request, and in the same order, i.e. the n'th m= line > of the response corresponds to the n'th line in the request. If the > caller can't or doesn't want to establish a particular stream it must > still have the m= line in the response: > > If caller and callee have no media formats in common for a particular > stream, the callee MUST return a session description containing the > particular "m=" line, but with the port number set to zero, and no > payload types listed. > > In your example the callee might return > > m=video 5000 RTP/AVP 31 > m=video 0 RTP/AVP > > Frankly, this method of referring to media streams isn't the most > wonderful aspect of SIP. Once upon a time there was a thread on a > specific issue relating to SDP media alignment: > > http://www-uk.hpl.hp.com/people/ak/confctrl/1999/msg00297.html > > > > > Should in these situations (multiple streams containing media of the > > same type) the "i" attribute of SDP be used? (or it is not intended for > > this?) > > > > m=video 1000 RTP/AVP 31 > > i= front camera > > m=video 1002 RTP/AVP 31 > > i= panoramic camera > > Something along these lines was actually proposed by Peter Peldan. The > idea was to associate a UID with media streams and then use that to > refer to them later, e.g. in the response to the initial INVITE and > later, when renegotiating streams using re-INVITEs. > > IMHO this would be a big improvement on the present method of referring > to streams by position in the initial INVITE. > > > > > This way B can choose wich one he wants to receive: > > > > m=video 5000 RTP/AVP 31 > > i= front camera > > > > This example may look pretty stupid, but when QoS preconditions are > > added to the SDP there are some useful scenarios for this. > > > > Anders > > -- > Anders Kristensen , > http://www-uk.hpl.hp.com/people/ak/ > Hewlett-Packard Labs, Bristol, UK ************************************ Igor Slepchin said >I think I misunderstood your intentions. No Igor, you were more correct the first time but anyhow: I believe the confusion seems to grow on both sides and it may be time to summarize what we know: 1. Current suggestion in SIP is that we should/must line up all media descriptors meaning that we cannot have one media-descriptor mapped to two on the other side, or that we cannot allow one media-session being described by two media-descriptors. If there are two media-descriptors in the callers SDP, the caller wants two sessions and the callee should accept both or send an error. 2. Ellemtel and HP-Labs plug-in architecture makes it desirable to allow two media-descriptor for the same media-session. We wish to be able to use two -- or more -- media descriptors for the same session. The callee could accept the call by only supporting one of them. What solutions do we see? Solution 1. We allow multiple media descriptors for one session and label every media-session with the i= field. There's no need to line up media descriptors. Advantage: Very flexible solution for using plug-ins. We do not tie up the SDP to a too strict specification that may prevent future -- yet unknown -- reasons for splitting session. Disadvatage: We get backward compatibility problems. The callee's UAS may not understand that the two media-descriptors belongs to the same session, and may open two streams. We may get synchronization problems when RTP-streams are switched between ports/modules. Solution 2. We keep the media-descriptor line-up requirement and make no changes. Advantage: No changes to the current spec. We do not risk the kind of synchronization problems described earlier. Disadvatage: We tie up the SDP so strict that it may cause problems for future session types that prefer to be splitted into multiple media descriptors for whatever reason. It may cause an unflexible plug-in architecture (which may be avoided to some extent by using the solution below) I believe solution 2 might be the best solution due to the problems of backwards compatibility only. I am not happy about causing such an inflexible SDP specification for SIP. Hopefully future session types can all be fit into one media descriptor? The problem with using multiple e.g audio-plug-ins may perhaps be solved by, in the UAC, automatically make another call with the other plug-in if the first fails due to non-acceptabel media descriptor? The user will in that case only notice a slight delay. For the callee there's no problem since his UAS may choose what plug-in to use based on the caller's SDP. We will only lose the possibility of switching between plug-ins during the call, which perhaps noone really wants anyway? Peter Peldan -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 09:29:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09436 for ; Tue, 7 Mar 2000 09:29:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A43CE52DE; Tue, 7 Mar 2000 09:27:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 10DCA52DD; Tue, 7 Mar 2000 09:27:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1A91B52DE for ; Tue, 7 Mar 2000 09:27:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 09:26:51 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 7 09:24:18 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA23150; Tue, 7 Mar 2000 09:26:48 -0500 (EST) Message-ID: <38C512F4.7547024@dynamicsoft.com> Date: Tue, 07 Mar 2000 09:32:20 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: HEMANT AGRAWAL Cc: sip@lists.research.bell-labs.com, Robert.Sparks@wcom.com Subject: Re: Activation of Call Forwarding in Proxy Server References: <004601bf87e6$34d6e670$6d1da4a4@wipsys.soft.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit By "activation", I assume you mean how these features are turned on by the users? Users can upload CPL scripts to specify the features they want. SIP itself does not specify ways to turn on and off features. -Jonathan R. HEMANT AGRAWAL wrote: > > Hi , > In Ref. to Sec. 2.5 "Call Forwarding Unconditional" etc of > "draft-sparks-sip-service-examples-00". > Can anybody tell me how to tell the proxy server "calls to me at my > registered URL should be forwarded to another URL." > Is there any feature activation procedures in SIP (In H.323, > H.450.3 have procedures for activating CFU etc. features in Gatekeeper) > > Regards, > Hemant > > _______________________________________________________ > Hemant Agrawal Tel:(Off.) 91-80-5539134 ext. > 407 > COE - Voice Over IP (Res.) 91-80-3499383 > Wipro Technologies - Telecom Solutions. > Email: hemant.agrawal@wipro.com > " Govindam adi-purusam tam aham bhajami" -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 09:50:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15509 for ; Tue, 7 Mar 2000 09:50:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D88BC52DC; Tue, 7 Mar 2000 09:47:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 56CAD52DF; Tue, 7 Mar 2000 09:47:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8D18B52DC for ; Tue, 7 Mar 2000 09:47:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 09:45:18 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Tue Mar 7 09:42:45 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id 3F5A7955; Tue, 7 Mar 2000 06:45:15 -0800 (PST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA22938; Tue, 7 Mar 2000 14:44:55 GMT Message-ID: <38C515FF.BF96F211@hplb.hpl.hp.com> Date: Tue, 07 Mar 2000 14:45:19 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: sip@lists.research.bell-labs.com, confctrl@ISI.EDU, Peter.Peldan@ellemtel.se Subject: Re: Mapping media streams References: <38C4F349.E694991D@hplb.hpl.hp.com> <38C50FCB.89DBD8A3@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > Hej Anders, > > Thanks for pointing out the URL with the previous discussion (I have > included a mail from Peter Peldan below). What was the final result of > the discussion? Peter and myself got tired of arguing first, so the spec didn't change ;-). More seriously, this was after SIP had made it to proposed standard, making it somewhat tricky to radically modify it. Also it isn't *that* big a deal - OK so UAs may not be able to freely use codecs from different RTP libraries within the same leg, but that's hardly the end of the world. I still think using explicit (and opaque) identifiers for media streams in SDP (or whatever session description language is used) is preferable as it's cleaner and simpler and probably less error prone than rearranging and matching SDP m= lines. > > Since I have seen no changes to the spec I guess the media alignment is > still done matching the nths "m" lines, right? Right. > > What about if the callee wants to add a media stream to the session? > The callee might want to send a new m line in the 200 OK. Should this be > allowed? I don't think anything in rfc 2543 disallows it, but I wouldn't have thought many UAs would handle it the way you'd want it to. Ours certainly wouldn't. The callee could accept the call and then try a re-INVITE, though. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 10:08:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19004 for ; Tue, 7 Mar 2000 10:08:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 013DE52E1; Tue, 7 Mar 2000 10:05:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 70E3D52DF; Tue, 7 Mar 2000 10:05:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B2F6C52E1 for ; Tue, 7 Mar 2000 10:05:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 10:04:29 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 7 10:01:56 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA23349 for ; Tue, 7 Mar 2000 10:04:39 -0500 (EST) Message-ID: <38C51BD3.45D02E2C@dynamicsoft.com> Date: Tue, 07 Mar 2000 10:10:11 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: What is a task force? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Given the numerous mails I received regarding the various new task forces, I thought I would take a moment to clarify what these task forces are, and what they are supposed to do. Task forces are also known as design teams. They are focused groups whose aim is to generate documents that are presented to the broader group. To be effective, they need to be small and be composed of people who actively contribute. If you are generally interested in a subject, and want to find out about it, or "lurk" as its called, the task force is not for you. Being part of the task force means you are committed to posting and working on generating a document in a timely fashion. Note that outputs of the task force are always subject to broader review from the main sip list. Task forces generally do their work via a separate mailing list. Depending on the group, there may be conference calls and possibly face to face meetings. It all depends on the level of commitment of the team members and the amount of work to be done in the given time frame. The new sip home line emulation service task force is first charged with determining the requirements for this service. Once that is done, they will generate an I-D which describes how to do it in SIP. I'm hoping for about 1-2 months effort till the I-D gets done. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 11:36:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05604 for ; Tue, 7 Mar 2000 11:36:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B98F552D5; Tue, 7 Mar 2000 11:33:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1F41D52DB; Tue, 7 Mar 2000 11:33:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 433EA52D5 for ; Tue, 7 Mar 2000 11:33:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 7 11:32:47 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 7 11:30:13 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA23856; Tue, 7 Mar 2000 11:32:51 -0500 (EST) Message-ID: <38C5307E.6DE767D4@dynamicsoft.com> Date: Tue, 07 Mar 2000 11:38:22 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: Gonzalo Camarillo , mmusic , sip Subject: Re: Sendonly in SDP References: <6525689B.00469488.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit archow@hss.hns.com wrote: > > * For send-only streams, the address and port number have no significance > and SHOULD be set to zero.* This is true now, but we have just recently realized this is not correct. The reason is RTCP - the SDP needs to convey the address where the recipient can send RTCP to. As a result, I think we do need to include an IP address and port. I think the port should be an even one (indicating where RTP would be received on, even though no RTP will ever be received), for consistency. RTCP would be sent to the port one higher. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 11:52:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08151 for ; Tue, 7 Mar 2000 11:52:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 46D9152DC; Tue, 7 Mar 2000 11:49:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AE5DB52DD; Tue, 7 Mar 2000 11:49:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 484CB52DC for ; Tue, 7 Mar 2000 11:49:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 11:47:06 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Tue Mar 7 11:44:32 EST 2000 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id RAA22848; Tue, 7 Mar 2000 17:47:03 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.75.22]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA22206; Tue, 7 Mar 2000 18:47:02 +0200 (EET) Message-ID: <38C532FB.A54436A3@lmf.ericsson.se> Date: Tue, 07 Mar 2000 18:48:59 +0200 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: jdrosen@dynamicsoft.com Cc: archow@hss.hns.com, confctrl@ISI.EDU, sip@lists.research.bell-labs.com, Miguel Angel Subject: Re: Sendonly in SDP References: <38C5307E.6DE767D4@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Also about appendix B. If we want to put the other party on hold we will set the "c" line to zero. Shouldn't we add "a=recvonly" to indicate that we are not going to send any packets either? Thanks, Gonzalo jdrosen@dynamicsoft.com wrote: > > archow@hss.hns.com wrote: > > > > * For send-only streams, the address and port number have no significance > > and SHOULD be set to zero.* > > This is true now, but we have just recently realized this is not > correct. The reason is RTCP - the SDP needs to convey the address where > the recipient can send RTCP to. As a result, I think we do need to > include an IP address and port. I think the port should be an even one > (indicating where RTP would be received on, even though no RTP will ever > be received), for consistency. RTCP would be sent to the port one > higher. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 11:55:20 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08933 for ; Tue, 7 Mar 2000 11:55:17 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 532F652DD; Tue, 7 Mar 2000 11:51:53 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4410D52E2; Tue, 7 Mar 2000 11:51:51 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F0B9C52DD for ; Tue, 7 Mar 2000 11:51:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 11:49:07 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 7 11:46:34 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA23922; Tue, 7 Mar 2000 11:45:08 -0500 (EST) Message-ID: <38C53360.68C06E8D@dynamicsoft.com> Date: Tue, 07 Mar 2000 11:50:40 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: Gonzalo Camarillo , sip@lists.research.bell-labs.com, confctrl@ISI.EDU, Peter.Peldan@ellemtel.se Subject: Re: Mapping media streams References: <38C4F349.E694991D@hplb.hpl.hp.com> <38C50FCB.89DBD8A3@lmf.ericsson.se> <38C515FF.BF96F211@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > I still think using explicit (and opaque) identifiers for media streams > in SDP (or whatever session description language is used) is preferable > as it's cleaner and simpler and probably less error prone than > rearranging and matching SDP m= lines. No doubt. The problem is backwards compatibility... > > > > What about if the callee wants to add a media stream to the session? > > The callee might want to send a new m line in the 200 OK. Should this be > > allowed? > > I don't think anything in rfc 2543 disallows it, but I wouldn't have > thought many UAs would handle it the way you'd want it to. Ours > certainly wouldn't. The callee could accept the call and then try a > re-INVITE, though. The spec doesn't detail adding and removing of media streams. The basic mechanism is there, though: 1. to add a stream, add an additional m line at the bottom in a re-INVITE. 2. to remove a stream, set its port to zero in a re-INVITE (2) is consistent with how a UAS rejects a stream offered by a UAC. We should be sure to add these to the next revision. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 12:04:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11253 for ; Tue, 7 Mar 2000 12:04:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9F4D352E2; Tue, 7 Mar 2000 12:01:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1369D52E4; Tue, 7 Mar 2000 12:01:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EB5E652E2 for ; Tue, 7 Mar 2000 12:01:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 12:00:41 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 7 11:58:08 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA24006; Tue, 7 Mar 2000 12:00:48 -0500 (EST) Message-ID: <38C5370B.C0795755@dynamicsoft.com> Date: Tue, 07 Mar 2000 12:06:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexei Prokofiev Cc: sip , sip_support@dynamicsoft.com, prj.men.sip@mera.ru Subject: Re: Several TCP connections for the same SIP transaction References: <009e01bf883a$dff1cdf0$fb3962c3@mera.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit It depends on how forgiving your client is. A server is supposed to send responses on the same connection the requests came from, if that connection is still open. If the client closes the connection before the response comes, the server should CANCEL. If, by chance, the CANCEL and the actual final response pass on the wire, the server is supposed to open a connection to the client to send the response. Sooo, a client will already need to handle incoming connections for responses, but only in this specific case. If a server opens a new connection to send a response, and the initial one is still open, the server has erred. What the client does (handle this or not) is at its discretion. Handling this may be easy since it already needs to deal with a similar case. -Jonathan R. > Alexei Prokofiev wrote: > > Hi, > > should a client UA accept replies of a transaction in case they are > sent > by a server UA via several TCP connections different from the one used > to send the request of the transaction? > > Thanks a lot! > > ----------- > Alexei Prokofiev, mailto:palx@null.net > Software Engeneer, > Mera Labs. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 12:33:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16572 for ; Tue, 7 Mar 2000 12:33:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6DDBC52E3; Tue, 7 Mar 2000 12:31:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E0DEE52E4; Tue, 7 Mar 2000 12:31:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C338152E3 for ; Tue, 7 Mar 2000 12:31:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 12:30:02 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 7 12:27:26 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA24121 for ; Tue, 7 Mar 2000 12:30:12 -0500 (EST) Message-ID: <38C53DEF.38649FF4@dynamicsoft.com> Date: Tue, 07 Mar 2000 12:35:43 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: SIP Supported Header Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I have just sent draft-ietf-sip-serverfeature-02.txt to IESG for consideration as proposed standard. This small but important extension clears the way for several other documents which depended on it, including the reliable provisional responses and session timer. I'd now like to try and focus some discussion on the reliable provisional responses draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-00.txt I have received no comments on this at all. I encourage people to take a look at it, and particularly comment on some of the open issues. For example, right now, cumulative acknowledgements are supported. Is this too complex? There also need to be some minor changes to align it with the final Supported header draft. I will also shorten the option tag to "prel" for provisional reliability. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 17:17:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04217 for ; Tue, 7 Mar 2000 17:17:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 80C2152B6; Tue, 7 Mar 2000 17:15:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EB54E52BB; Tue, 7 Mar 2000 17:15:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 33C6152B6 for ; Tue, 7 Mar 2000 17:15:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 7 17:13:14 EST 2000 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Tue Mar 7 17:10:38 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0FR200077OE1H8@firewall.mcit.com> for sip@lists.research.bell-labs.com; Tue, 7 Mar 2000 22:13:13 +0000 (GMT) Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id WAA14334; Tue, 07 Mar 2000 22:13:18 +0000 (GMT) Received: from dwillispc8 ([166.35.148.173]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000307221312.RWIL608@dwillispc8>; Tue, 07 Mar 2000 22:13:12 +0000 Date: Tue, 07 Mar 2000 16:12:23 -0600 From: Dean Willis Subject: RE: Activation of Call Forwarding in Proxy Server In-reply-to: <004601bf87e6$34d6e670$6d1da4a4@wipsys.soft.net> To: HEMANT AGRAWAL Cc: sip@lists.research.bell-labs.com Message-id: <001601bf8882$36dc5a80$ad9423a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit How a features is activated (or even defined) is very much up to the logic of the feature server. The system I use works in several ways. I initially define a user profile that contains one or more device entries and zero or more schedules and zero or more rules for calling parties. There is also a web page for turning features like unconditional forwarding on and off. Some of the device entries are "dynamic" -- they have to have an active registration to be considered. Others are static, and do not require registrations. An incoming call is iterated through the device enries and the schedule and the contacts. It may be routed to a phone, or voice mail, or whatever, perhaps dependent on the time of day, the identity of the caller, the state of my devices, and additional application logic. So, I have several ways to change what is happening: 1) I can use the web interface to change my profile. 2) One or more of the devices can register on my behalf. 3) A third-party system can submit a registration on my behalf. With CPL, we could add: 1) I upload a new CPL using a file transfer 2) I upload a new CPL with a REGISTER message 3) I use a GUI-tool on a web server to build and apply a new CPL With CGI, options 1 and 3 above apply . . , and so on. The question you aske is something akin to "How do I forward my email?", where the options include a .forward file, an /etc/aliases entry, a mailertable, a procmail script, etc. Many solutions might apply. -- Dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of HEMANT > AGRAWAL > Sent: Monday, March 06, 2000 9:36 PM > To: sip@lists.research.bell-labs.com; Robert.Sparks@wcom.com > Cc: jdrosen@dynamicsoft.com > Subject: Activation of Call Forwarding in Proxy Server > > > Hi , > In Ref. to Sec. 2.5 "Call Forwarding Unconditional" etc of > "draft-sparks-sip-service-examples-00". > Can anybody tell me how to tell the proxy server "calls to me at my > registered URL should be forwarded to another URL." > Is there any feature activation procedures in SIP (In H.323, > H.450.3 have procedures for activating CFU etc. features in Gatekeeper) > > Regards, > Hemant > > > _______________________________________________________ > Hemant Agrawal Tel:(Off.) > 91-80-5539134 ext. > 407 > COE - Voice Over IP (Res.) 91-80-3499383 > Wipro Technologies - Telecom Solutions. > Email: hemant.agrawal@wipro.com > " Govindam adi-purusam tam aham bhajami" > > > From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 7 23:17:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19745 for ; Tue, 7 Mar 2000 23:17:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D04F952B6; Tue, 7 Mar 2000 23:15:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A039952BB; Tue, 7 Mar 2000 23:15:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 774EC52B6 for ; Tue, 7 Mar 2000 23:15:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 23:14:11 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Tue Mar 7 23:11:29 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA20680; Wed, 8 Mar 2000 10:11:11 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525689C.00175183 ; Wed, 8 Mar 2000 09:44:41 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Message-ID: <6525689C.0017508E.00@sampark.hss.hns.com> Date: Wed, 8 Mar 2000 09:44:38 +0530 Subject: Re: Provisional Response Draft (Was: SIP Supported Header) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, I have two basic questions on provisional responses draft. 1. Do we need the final 200 OK after PRACK ? The UA (UA1) which sent the rel. prov. response wanted to make sure that this reached the UA it was designated for (UA2). Just like ACK does not need a confirmation in INVITE, does PRACK need it ? Once UA1 received a PRACK, it knows UA2 received it. Does UA2 need to know that UA1 received his PRACK confirmation ? If he hasnt received, as it is the prov. response will be retransmitted. Howver, there seems to be a mention of a PRACK containing media desc. body - is this anyway realted to 200K being mandatory for PRACK ? 2.Cumulative response: I guess the advantage of this was that one could reduce network traffic by block PRACKing many informative responses. However, I feel it would be simpler if it only responded to one prov. response and not many - Im not sure if it really is so helpful wrt network traffic compared to the extra work the UAs will have to do just to correlate all the responses, ensure there are no holes in seq numbering, etc. Anyway, this is a subjective opinion :-) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Jonathan Rosenberg on 03/07/2000 11:05:43 PM To: sip@lists.research.bell-labs.com cc: Subject: SIP Supported Header Folks, I have just sent draft-ietf-sip-serverfeature-02.txt to IESG for consideration as proposed standard. This small but important extension clears the way for several other documents which depended on it, including the reliable provisional responses and session timer. I'd now like to try and focus some discussion on the reliable provisional responses draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-00.txt I have received no comments on this at all. I encourage people to take a look at it, and particularly comment on some of the open issues. For example, right now, cumulative acknowledgements are supported. Is this too complex? There also need to be some minor changes to align it with the final Supported header draft. I will also shorten the option tag to "prel" for provisional reliability. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 00:07:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01797 for ; Wed, 8 Mar 2000 00:07:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 958C652C4; Tue, 7 Mar 2000 23:49:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1281C52D4; Tue, 7 Mar 2000 23:49:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D769252C4 for ; Tue, 7 Mar 2000 23:49:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 23:48:59 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 7 23:46:23 EST 2000 Received: from dynamicsoft.com (1Cust36.tnt1.freehold.nj.da.uu.net [63.17.113.36]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA25951; Tue, 7 Mar 2000 23:48:37 -0500 (EST) Message-ID: <38C5DCF2.2FE0FA02@dynamicsoft.com> Date: Tue, 07 Mar 2000 23:54:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft (Was: SIP Supported Header) References: <6525689C.0017508E.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit archow@hss.hns.com wrote: > > Hi, > I have two basic questions on provisional responses draft. > > 1. Do we need the final 200 OK after PRACK ? The UA (UA1) which sent the > rel. prov. response wanted to make sure that this reached > the UA it was designated for (UA2). Just like ACK does not need a > confirmation in INVITE, does PRACK need it ? Once UA1 > received a PRACK, it knows UA2 received it. Does UA2 need to know that > UA1 received his PRACK confirmation ? If he hasnt received, as it is the > prov. response will be retransmitted. Strictly speaking, for reliability purposes, the 200 OK to PRACK is not needed. However, I believe it should to be there for the sake of ensuring that all unknown requests at proxies can be treated as if they were BYE (in terms of routing/processing/transmission rules). Consider a proxy that doesn't know PRACK. It receives one, and forwards it. It will believe that the rules are the same as for BYE, and thus expect a response. This means it will maintain transaction state until some timer has expired. Its even possible that the proxy might send CANCEL on expiration of the timer, and then send a 408 response to the PRACK. All this would be reasonable if PRACK has a response. If PRACK has no response, proxies really MUST understand it, since the previous behavior is going to confuse it and other entities involved. This means we need to add a Proxy-Require header. I don't want to do that, since it affects interop and the ability to easily get this out there. > > Howver, there seems to be a mention of a PRACK containing media desc. body > - is this anyway realted to 200K being mandatory for PRACK ? No, this is unrelated. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 00:12:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03514 for ; Wed, 8 Mar 2000 00:12:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 428F652D4; Wed, 8 Mar 2000 00:09:47 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 61DB152D5; Wed, 8 Mar 2000 00:09:45 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 413D952D4 for ; Wed, 8 Mar 2000 00:09:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 00:07:36 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Mar 8 00:04:59 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust211.tnt3.long-branch.nj.da.uu.net [63.25.227.211]) id QQifot09362; Wed, 8 Mar 2000 04:59:13 GMT Message-ID: <38C5DE84.596F16D7@dynamicsoft.com> Date: Wed, 08 Mar 2000 00:00:52 -0500 From: Igor Slepchin X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: Jonathan Rosenberg , sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft (Was: SIP Supported Header) References: <6525689C.0017508E.00@sampark.hss.hns.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit archow@hss.hns.com wrote: > > 1. Do we need the final 200 OK after PRACK ? Yes, we do. Reliability of provisional responses is end-to-end. One consequence of this is that proxies need not know anything about draft-ietf-sip-100rel-00.txt; thus, the proxies will treat PRACK as any non-INVITE request and will retransmit it until they see a final response. The 200 OK is needed to stop these retransmissions. > 2.Cumulative response: I guess the advantage of this was that one could > reduce network traffic by block PRACKing many informative > responses. However, I feel it would be simpler if it only responded to one > prov. response and not many - Im not sure if it really is so helpful wrt > network traffic compared to the extra work the UAs will have to do just to > correlate all the responses, ensure there are no > holes in seq numbering, etc. Anyway, this is a subjective opinion :-) I think that processing cumulative PRACKs should be fairly straightforward: you just need to check the RAck value and stop retransmitting responses whose RSeq is lower or equal to the RAck you received. Accumulating PRACKs may be more tricky as you'd need to take care not to linger too long as the other side might time out if it does not see a PRACK within certain time interval. However, the draft does not require that you do such accumulation, you just need to be prepared to receive PRACKs accumulated by someone else. --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 00:16:36 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04786 for ; Wed, 8 Mar 2000 00:16:36 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 636AE52D5; Wed, 8 Mar 2000 00:12:38 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D085452D6; Wed, 8 Mar 2000 00:12:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5A30B52D5 for ; Wed, 8 Mar 2000 00:11:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 00:09:39 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 8 00:07:03 EST 2000 Received: from dynamicsoft.com (1Cust36.tnt1.freehold.nj.da.uu.net [63.17.113.36]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA25980; Wed, 8 Mar 2000 00:09:42 -0500 (EST) Message-ID: <38C5E1E4.D840153E@dynamicsoft.com> Date: Wed, 08 Mar 2000 00:15:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Ford Cc: archow@hss.hns.com, Gonzalo Camarillo , mmusic , sip Subject: Re: Sendonly in SDP References: <726A4C58DBA56E409F3D3563A8BF953C09ED30@airstream-corp.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Peter Ford wrote: > > how about a host name and a port? or a URI? .... SDP does allow a host name to appear in the c line for the address, although I haven't seen that done much, and I'm not sure how useful it is. This address needs to be the address of the machine receiving the media. For many users today, these machines are dial-up or on internal networks and often have no host name entries in DNS. As for a URI, SDP simply doesn't allow it. I'm not sure what it would mean for the media destination to be a URI. Gonzalo wrote: > Also about appendix B. If we want to put the other party on hold we will > set the "c" line to zero. > > Shouldn't we add "a=recvonly" to indicate that we are not going to send > any packets either? > Doesn't much matter, I guess. The semantic is derived from the port number. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 00:21:24 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06383 for ; Wed, 8 Mar 2000 00:21:23 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CA05752D6; Wed, 8 Mar 2000 00:16:30 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9E5E652DB; Wed, 8 Mar 2000 00:16:29 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6FF4952D6 for ; Wed, 8 Mar 2000 00:15:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 00:13:21 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 8 00:10:35 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA26253; Wed, 8 Mar 2000 11:09:46 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525689C.001CA52A ; Wed, 8 Mar 2000 10:42:52 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Igor Slepchin Cc: archow@hss.hns.com, Jonathan Rosenberg , sip@lists.research.bell-labs.com Message-ID: <6525689C.001CA41F.00@sampark.hss.hns.com> Date: Wed, 8 Mar 2000 10:42:49 +0530 Subject: Re: Provisional Response Draft (Was: SIP Supported Header) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk I agree the algorithm is not complex - just that I was wondering does this PRACK really require a special case of request response matching ? I am not sure if we really gain much by having one response to many prov. responses - are there practical cases where there are so may prov. responses in a transaction that warrants a cumulative response to be specified ? Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems igor> I think that processing cumulative PRACKs should be fairly igor> straightforward: you just need to check the RAck value and stop igor> retransmitting responses whose RSeq is lower or equal to the RAck you igor> received. Accumulating PRACKs may be more tricky as you'd need to take igor> care not to linger too long as the other side might time out if it does igor> not see a PRACK within certain time interval. However, the draft does igor> not require that you do such accumulation, you just need to be prepared igor> to receive PRACKs accumulated by someone else. From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 00:46:39 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12527 for ; Wed, 8 Mar 2000 00:46:39 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8F93352BB; Wed, 8 Mar 2000 00:42:00 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CEDF652DC; Wed, 8 Mar 2000 00:41:59 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AEADE52BB for ; Wed, 8 Mar 2000 00:41:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 00:40:47 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Mar 8 00:38:10 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust211.tnt3.long-branch.nj.da.uu.net [63.25.227.211]) id QQifow17493; Wed, 8 Mar 2000 05:40:44 GMT Message-ID: <38C5E83F.903389F4@dynamicsoft.com> Date: Wed, 08 Mar 2000 00:42:23 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: Jonathan Rosenberg , sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft (Was: SIP Supported Header) References: <6525689C.001CA41F.00@sampark.hss.hns.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I think it's fairly hard to say at this time how widely reliable provisional responses will be used and if there will appear any widespread scenarios where such responses are sent in quick succession. However, handling cumulative PRACKs seems to add little enough complexity to keep them just in case they prove useful. I don't have a very strong opinion on this, though. Also, note that you'll need special code to match PRACKs to responses anyway; usual SIP call leg or request/response matching rules won't work here. --- Igor Slepchin archow@hss.hns.com wrote: > > I agree the algorithm is not complex - just that I was wondering does this > PRACK really require a special case of request response matching ? I am not > sure if we really gain much by having one response to many prov. responses > - are there practical cases where there are so may prov. responses in a > transaction that warrants a cumulative response to be specified ? > > Regds > Arjun From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 01:24:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24422 for ; Wed, 8 Mar 2000 01:24:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 72CA552DC; Wed, 8 Mar 2000 01:21:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3F5C452DD; Wed, 8 Mar 2000 01:21:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 2877652DC for ; Wed, 8 Mar 2000 01:21:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 8 01:19:51 EST 2000 Received: from exchangesvr.nuera.com ([204.216.240.124]) by dusty; Wed Mar 8 01:17:15 EST 2000 Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Mar 2000 22:19:53 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@lists.research.bell-labs.com'" Subject: Tag Values. Date: Tue, 7 Mar 2000 22:19:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk I have a couple of questions regarding the tag value added to the {To} header. The SIP RFC says that the tag value should be a UUID and (from a previous post) that the UUID should/may be constructed using the standard format. The RFC also says that "The "tag" value MUST be globally unique and cryptographically random with at least 32 bits of randomness." So I take it that the tag can either be a UUID or 32bit random number ? It has puzzled me why many traces have "tag=xxxxxxx" where xxxxxx is a decimal number usually much less than 2^31. Why decimal and so small ? [Whether the field is hex or decimal or UUID shouldn't matter since a case-insensitive string comparison of the field is used, correct?] What is the current best practice for adding a tag when there is only one Via line present? I think the spec uses an implicit MAY for this case but has this been upgraded/clarified to a SHOULD or MUST ? That is, a UAS SHOULD/MUST add a tag to final responses if there is one Via header (and of course MUST if there are multiple Via's). Thanks, Regards, Robert. From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 01:37:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29636 for ; Wed, 8 Mar 2000 01:37:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AD6D052E1; Wed, 8 Mar 2000 01:34:46 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 20B3152DF; Wed, 8 Mar 2000 01:34:46 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6E4BE52B6 for ; Tue, 7 Mar 2000 17:51:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 7 17:49:09 EST 2000 Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by dusty; Tue Mar 7 17:46:33 EST 2000 Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Mar 2000 14:30:57 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Mar 2000 14:30:56 -0800 Message-ID: <726A4C58DBA56E409F3D3563A8BF953C09ED30@airstream-corp.platinum.corp.microsoft.com> From: Peter Ford To: "'Jonathan Rosenberg'" , archow@hss.hns.com Cc: Gonzalo Camarillo , mmusic , sip Subject: RE: Sendonly in SDP Date: Tue, 7 Mar 2000 14:05:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk how about a host name and a port? or a URI? .... cheers, peterf -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, March 07, 2000 8:38 AM To: archow@hss.hns.com Cc: Gonzalo Camarillo; mmusic; sip Subject: Re: Sendonly in SDP archow@hss.hns.com wrote: > > * For send-only streams, the address and port number have no significance > and SHOULD be set to zero.* This is true now, but we have just recently realized this is not correct. The reason is RTCP - the SDP needs to convey the address where the recipient can send RTCP to. As a result, I think we do need to include an IP address and port. I think the port should be an even one (indicating where RTP would be received on, even though no RTP will ever be received), for consistency. RTCP would be sent to the port one higher. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 05:08:25 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08493 for ; Wed, 8 Mar 2000 05:08:25 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CB47352D4; Wed, 8 Mar 2000 05:05:33 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4E88052AB; Wed, 8 Mar 2000 05:05:31 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 4057E52AB for ; Wed, 8 Mar 2000 05:05:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 8 05:04:14 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 8 05:01:36 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id QAA22231; Wed, 8 Mar 2000 16:01:23 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525689C.00375A3B ; Wed, 8 Mar 2000 15:34:35 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: sip@lists.research.bell-labs.com Message-ID: <6525689C.0037596A.00@sampark.hss.hns.com> Date: Wed, 8 Mar 2000 15:34:32 +0530 Subject: SIP for PSTN services Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, We need to use SIP to connect to PSTN side Fax, click to dial etc. I read through the PINT draft which is supposeldy catering to this type of service. However, I wanted to know which approach to select. Is PINT the standard way for PSTN service interaction ? It seems whatever PINT states can be done with regular SIP - or is that incorrect And is my understanding that PINT is nothing but SIP/SDP with some extensions and is analogous to the various SIP extensions drafts that are in existence today ? Thx Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 08:04:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27871 for ; Wed, 8 Mar 2000 08:04:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 87F3952B6; Wed, 8 Mar 2000 08:01:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EDFA152BB; Wed, 8 Mar 2000 08:01:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 921BE52B6 for ; Wed, 8 Mar 2000 08:01:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 08:00:15 EST 2000 Received: from mail-blue.research.att.com ([135.207.30.102]) by dusty; Wed Mar 8 07:57:39 EST 2000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 6568B4CE11; Wed, 8 Mar 2000 08:00:14 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id IAA11427; Wed, 8 Mar 2000 08:00:13 -0500 (EST) Received: (from kkrama@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id HAA02201; Wed, 8 Mar 2000 07:59:39 -0500 (EST) From: "K. K. Ramakrishnan" Message-Id: <1000308075938.ZM2199@windsor.research.att.com> Date: Wed, 8 Mar 2000 07:59:38 -0500 In-Reply-To: archow@hss.hns.com "Re: Provisional Response Draft (Was: SIP Supported Header)" (Mar 8, 9:44am) References: <6525689C.0017508E.00@sampark.hss.hns.com> X-Mailer: Z-Mail (4.0.1 13Jan97) To: archow@hss.hns.com, Jonathan Rosenberg Subject: Re: Provisional Response Draft Cc: sip@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk We had the discussion on having a 200 OK response for the Ack. (PRACK) of a Provisional Response to an INVITE while working on a proposal to go from a two-stage INVITE scheme to one having a single stage INVITE, as part of the DCS effort. One of our concerns was (upstream) messaging overhead from the perspective of latency and bandwidth consumption. In my mind, the PRACK is used to acknowledge a provisional response. To then require a further acknowledgment (200 OK) of this acknowledgment (PRACK) seemed to be excessive overhead. Purely from the perspective of recovery from packet loss, the reaction to the loss of the PRACK should be not that different fromt he reaction to the loss of the provisional response (e.g., losing the 183). We have a final response (200 OK) for the original INVITE anyway. In our case, the PRACK and the (hopefully unecessary) 200 OK go end-end without going through proxies. It seemed to us that in such a situation, having the 200 OK was even more gratuitous because it didn't have some of the issues about proxies keeping transaction state around. I appreciate the issues of having to clear transactional state at the proxies. But, one has to do that anyway with timers if the UAS (terminal responding to the PRACK) doesn't send the 200 OK for some reason. I also appreciate the need to not have special casing for methods - but is this extra messaging coming about because we chose to have the PRACK as a "method"? On the issue of backwards compatibility, couldn't we say that proxies shouldn't be creating transaction state for things it doesn't understand? It'd be nice not to require the 200 OK for the PRACK... K. K. Ramakrishnan -- K. K. Ramakrishnan Email:kkrama@research.att.com AT&T Labs-Research, Rm. A155 Tel: (973)360-8766 180 Park Ave, Florham Park, N.J. 07932 Fax: (973) 360-8050 URL: http://www.research.att.com/info/kkrama From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 08:31:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06662 for ; Wed, 8 Mar 2000 08:31:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5482952BB; Wed, 8 Mar 2000 08:29:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A706952C4; Wed, 8 Mar 2000 08:29:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A715A52BB for ; Wed, 8 Mar 2000 08:29:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 08:27:29 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Wed Mar 8 08:24:53 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id B022E672; Wed, 8 Mar 2000 05:27:26 -0800 (PST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA15416; Wed, 8 Mar 2000 13:27:25 GMT Message-ID: <38C65556.FB08F43E@hplb.hpl.hp.com> Date: Wed, 08 Mar 2000 13:27:50 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "K. K. Ramakrishnan" Cc: archow@hss.hns.com, Jonathan Rosenberg , sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft References: <6525689C.0017508E.00@sampark.hss.hns.com> <1000308075938.ZM2199@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "K. K. Ramakrishnan" wrote: > > I also appreciate the need to not have special casing for methods - > but is this extra messaging coming about because we chose to > have the PRACK as a "method"? On the issue of backwards compatibility, > couldn't we say that proxies shouldn't be creating transaction state > for things it doesn't understand? This proposal is itself not backwards compatible. Also, it doesn't seem quite right - it would mean, for example, that proxies cannot fork on requests they do not know. This seems like a big limitation. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 08:51:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13951 for ; Wed, 8 Mar 2000 08:51:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9167A52AB; Wed, 8 Mar 2000 08:49:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1001F52B6; Wed, 8 Mar 2000 08:49:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9D8CF52AB for ; Wed, 8 Mar 2000 08:49:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 08:47:39 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Wed Mar 8 08:45:03 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id 29EA171B; Wed, 8 Mar 2000 05:47:37 -0800 (PST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA16336; Wed, 8 Mar 2000 13:47:35 GMT Message-ID: <38C65A11.C2551163@hplb.hpl.hp.com> Date: Wed, 08 Mar 2000 13:48:01 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft References: <38C53DEF.38649FF4@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The draft talks about when it's OK to generate new reliable responses for a transaction, but it doesn't seem to say anything about whether final responses can be generated by a UAS which has outstanding unacknowledged reliable responses. I believe the UAS must be allowed to generate a final response at any time. The question is what happens with existing 'orphan' reliable responses and corresponding PRACKS. They can either terminate normally, i.e. the UAS continue retransmitting those reliable responses as it would have done had a final response not been sent and likewise the UAC still PRACKS them, or else maybe they could be terminated somehow - the UAS stops retransmitting them, and the UAC never PRACKS anything for which it has received a final response. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 09:42:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02082 for ; Wed, 8 Mar 2000 09:41:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DDCA252BB; Wed, 8 Mar 2000 09:39:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6462D52C4; Wed, 8 Mar 2000 09:39:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DB6A152BB for ; Wed, 8 Mar 2000 09:39:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 09:38:25 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Mar 8 09:35:49 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA01352; Wed, 8 Mar 2000 09:38:22 -0500 (EST) Message-ID: <38C665DB.3C8622BF@cs.columbia.edu> Date: Wed, 08 Mar 2000 09:38:19 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: adam.roach@ericsson.com, sip@lists.research.bell-labs.com Subject: draft-roach-sip-acb, draft-roach-sip-subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Some quick comments: - It would be nice to align the event notification as much as possible with PINT, since PINT is intended as a SIP profile. If their model is broken, it needs to be fixed. (It may well may sense to extract the event mechanism from PINT and have a common draft.) - Expires: It might be cleaner to structure this similar to the Contact mechanism in REGISTER. This also makes it possible to perform several actions atomically. Something like Event: waterboiling ;expires=3600 , dinnerdone;expires=7200 (I'm not sure that putting this is in the header is necessarily the best solution, but that's a separate discussion.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 11:16:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06085 for ; Wed, 8 Mar 2000 11:16:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2533D52AB; Wed, 8 Mar 2000 11:13:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 94CF452B6; Wed, 8 Mar 2000 11:13:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8568652AB for ; Wed, 8 Mar 2000 11:13:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 11:11:19 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Wed Mar 8 11:08:42 EST 2000 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FR400H0J2AJIT@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 8 Mar 2000 16:11:12 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by omzrelay.mcit.com (8.8.7/) with ESMTP id QAA25936 for ; Wed, 08 Mar 2000 16:11:04 +0000 (GMT) Received: from wcom.com ([166.33.132.111]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with ESMTP id <20000308161036.WODI613@wcom.com> for ; Wed, 08 Mar 2000 16:10:36 +0000 Date: Wed, 08 Mar 2000 10:11:42 -0600 From: Alan Johnston Subject: Re: I-D ACTION:draft-ietf-sip-call-flows-00.txt To: sip@lists.research.bell-labs.com Message-id: <38C67BBE.9C78F6DE@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200003071130.GAA29529@ietf.org> Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit This is the second draft of the Call Flows document (first draft was titled draft-johnston-sip-call-flows-00.txt before it was accepted as a working group draft). The major changes from the first draft are: - Converted all figures to ASCII art. - Incorporated "SIP Telephony Service Examples with Call Flows" (Sparks et al), draft-sparks-sip-service-examples-00, and also SIP Test Messages from the 2nd Bakeoff (Rosenberg and Schulzrinne) into the document. - Fixed assorted typos. - Made references to ISUP explicitly ANSI and added some comments on ITU and ETSI. - Fixed CANCEL mistakes (use of tags, end to end acknowledgments, etc.) - Added unique Authentication headers for each message. - Added Reliable Provisional Responses (PRACK) to scenario 4.1.2 for 183 Session Progress - Added simple SIP to SIP call without proxies 3.1.1 - Fixed "phone-context" and phone number handling in SIP URLs Any comments on the draft are greatly appreciated. Thanks to all the authors and the Call Flows Design Team. Alan Johnston MCI WorldCom Internet-Drafts@ietf.org wrote: > > 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 Telephony Call Flow Examples > Author(s) : A. Johnston, S. Donovan, R. Sparks,C. Cunningham, > K. Summers, D. Willis, J. Rosenberg, H. Schulzrinne, > Filename : draft-ietf-sip-call-flows-00.txt > Pages : 268 > Date : 06-Mar-00 > > This document gives examples of SIP (Session Initiation Protocol) > call flows for IP telephony and service examples. Elements in these > call flows include SIP User Agents and Clients, SIP Proxy and > Redirect Servers, and Gateways to the PSTN (Public Switch Telephone > Network). IP telephony scenarios include SIP Registration, SIP to > SIP calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway > via SIP. Call flow diagrams and message details are shown. PSTN > telephony protocols are illustrated using ISDN (Integrated Services > Digital Network), ANSI ISUP (ISDN User Part), and FGB (Feature Group > B) circuit associated signaling. PSTN calls are illustrated using > global telephone numbers from the PSTN and private extensions served > on by a PBX (Private Branch Exchange). Telephony service examples > illustrated with call flows include call hold, transfer, forwarding, > screening, and Find-Me. Example SIP messages used for testing during > SIP 'bakeoff' events include SIP 'torture test' messages, and > messages with invalid parameters, methods, and tags. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-00.txt > > 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-call-flows-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-call-flows-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. > > -------------------------------------------------------------------------------- > Content-Type: text/plain > Content-ID: <20000306120723.I-D@ietf.org> From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 13:32:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21481 for ; Wed, 8 Mar 2000 13:32:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2E48E52B6; Wed, 8 Mar 2000 13:29:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7B5A352C4; Wed, 8 Mar 2000 13:29:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5570D52B6 for ; Wed, 8 Mar 2000 13:29:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 13:27:41 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 8 13:25:05 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA27206; Wed, 8 Mar 2000 13:23:21 -0500 (EST) Message-ID: <38C69BE9.3882576D@dynamicsoft.com> Date: Wed, 08 Mar 2000 13:28:57 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: "K. K. Ramakrishnan" , archow@hss.hns.com, sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft References: <6525689C.0017508E.00@sampark.hss.hns.com> <1000308075938.ZM2199@windsor.research.att.com> <38C65556.FB08F43E@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > "K. K. Ramakrishnan" wrote: > > > > I also appreciate the need to not have special casing for methods - > > but is this extra messaging coming about because we chose to > > have the PRACK as a "method"? On the issue of backwards compatibility, > > couldn't we say that proxies shouldn't be creating transaction state > > for things it doesn't understand? > > This proposal is itself not backwards compatible. Also, it doesn't seem > quite right - it would mean, for example, that proxies cannot fork on > requests they do not know. This seems like a big limitation. I agree completely here with Anders. The spec clearly defines handling for unknown requests as if they were BYE. As one of the design principles of SIP, we've really tried to make it a fairly general purpose protocol. Many of the features and capabilities have broad applicability and usage. Often, the result of this kind of a decision is a tradeoff- messages are a little bigger, or more information is sent, when its not always needed. I'd really like to keep with that design philosophy. Having special case methods to cover every new case, and requiring tons of Proxy-Requires to make it all work, ends up resulting in a tangled mess of a protocol that doesn't interoperate. Please, lets stick with the request-response model for all new methods. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 17:47:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04656 for ; Wed, 8 Mar 2000 17:47:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4476252D6; Wed, 8 Mar 2000 17:42:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 862D252DC; Wed, 8 Mar 2000 17:42:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1382B52AB for ; Wed, 8 Mar 2000 16:17:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 16:15:58 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Wed Mar 8 16:13:22 EST 2000 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id PAA20046 for ; Wed, 8 Mar 2000 15:15:55 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id PAA25714 for ; Wed, 8 Mar 2000 15:15:55 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA05175 for ; Wed, 8 Mar 2000 15:15:54 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id PAA00587 for sip@lists.research.bell-labs.com; Wed, 8 Mar 2000 15:15:53 -0600 (CST) Message-Id: <200003082115.PAA00587@b04a24.exu.ericsson.se> Subject: Two New Drafts To: sip@lists.research.bell-labs.com Date: Wed, 8 Mar 2000 15:15:52 -0600 (CST) From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit There are two new drafts on the IETF web site. The first one is an attempt at formalising a general, extensible event notification for SIP using SUBSCRIBE and NOTIFY. The second draft demonstrates an application of this event notification (using an auto-call-back service), along with callflows. --------------------------------------------------------------------------- Title: Event Notification in SIP Abstract: This document describes an extension to the Session Initiation Protocol (SIP) [1] . The purpose of this extension is to provide a generic and extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occured. Concrete uses of the mechanism described in this document may be standardized in the future. http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.txt --------------------------------------------------------------------------- Title: Automatic Call Back Service in SIP Abstract: This document describes a proposed implementation of an Automatic Call Back (ACB) service using SIP. This service is somtimes refered to as "camp on extension," "call again," "automatic redial," and "automatic recall." http://search.ietf.org/internet-drafts/draft-roach-sip-acb-00.txt -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 8 17:49:12 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05246 for ; Wed, 8 Mar 2000 17:49:12 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6E00652C8; Wed, 8 Mar 2000 17:43:08 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8CD8A52DA; Wed, 8 Mar 2000 17:43:03 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EBE5552B6 for ; Wed, 8 Mar 2000 06:33:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 06:31:22 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Wed Mar 8 06:28:46 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28364; Wed, 8 Mar 2000 06:31:09 -0500 (EST) Message-Id: <200003081131.GAA28364@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-roach-sip-subscribe-notify-00.txt Date: Wed, 08 Mar 2000 06:31:09 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Event Notification in SIP Author(s) : A. Roach Filename : draft-roach-sip-subscribe-notify-00.txt Pages : 8 Date : 07-Mar-00 This document describes an extension to the Session Initiation Protocol (SIP) [1] . The purpose of this extension is to provide a generic and extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occured. Concrete uses of the mechanism described in this document may be standardized in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.txt 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-roach-sip-subscribe-notify-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-roach-sip-subscribe-notify-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: <20000307114100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-roach-sip-subscribe-notify-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-roach-sip-subscribe-notify-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000307114100.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 08:30:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01692 for ; Thu, 9 Mar 2000 08:30:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E6B3D52AB; Thu, 9 Mar 2000 08:27:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 67E5052C8; Thu, 9 Mar 2000 08:27:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 966D052AB for ; Thu, 9 Mar 2000 08:27:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 9 08:26:18 EST 2000 Received: from qhars002.nortel.com ([192.100.101.19]) by dusty; Thu Mar 9 08:23:42 EST 2000 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Thu, 9 Mar 2000 13:17:55 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Mar 2000 13:17:54 -0000 Message-ID: <61ABD11436FED21192440000F81F3E36033118F5@nwcwi1a.europe.nortel.com> From: "Joshua Moloney" To: sip@lists.research.bell-labs.com Subject: BYE request and CSeq value Date: Thu, 9 Mar 2000 13:17:50 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF89C9.E06CD988" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF89C9.E06CD988 Content-Type: text/plain Hi all, I have a question regarding BYE requests and the value of CSeq. It regards the behaviour of a User Agent that receives a BYE request for an existing session with a corrupt CSeq value. draft-ietf-mmusic-sip-new-00 says: "A BYE request with a CSeq that is not higher should cause a 400 response to be generated" (section 6.18). Section 10.1.1. follows this up (generalises the rule): "When a user agent server recieves a request, it checks the [Call-ID, To tag, From etc], the CSeq header field value. If less than or equal to the current sequence number, the request is a retransmission". Section 10.1.1 implies that an isomorphic request (the retransmission mentioned above) should be discarded, and an appropriate response sent out. It also implies that the server state should not be changed. If the server state should not be changed, then presumably the client's request to end the session is denied. Based on the above statements, here's my question: How is it possible for a user agent to terminate a session when it has somehow lost track of the sequence (CSeq value)? Cheers, Josh Moloney Nortel Networks - Public Networks Development ------_=_NextPart_001_01BF89C9.E06CD988 Content-Type: text/html Content-Transfer-Encoding: quoted-printable BYE request and CSeq value

Hi all,

I have a question regarding BYE = requests and the value of CSeq. It regards the behaviour of a User = Agent that receives a BYE request for an existing session with a = corrupt CSeq value.

draft-ietf-mmusic-sip-new-00 = says:
"A BYE request with a CSeq that = is not higher should cause a 400 response to be generated" = (section 6.18).

Section 10.1.1. follows this up = (generalises the rule):
"When a user agent server = recieves a request, it checks the [Call-ID, To tag, From etc], the CSeq = header field value. If less than or equal to the current sequence = number, the request is a retransmission".

Section 10.1.1 implies that an = isomorphic request (the retransmission mentioned above) should be = discarded, and an appropriate response sent out. It also implies that = the server state should not be changed.

If the server state should not be = changed, then presumably the client's request to end the session is = denied.

Based on the above statements, here's = my question:

How is it possible for a user agent to = terminate a session when it has somehow lost track of the sequence = (CSeq value)?

Cheers,

Josh Moloney
Nortel = Networks -    Public Networks = Development

------_=_NextPart_001_01BF89C9.E06CD988-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 11:06:22 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20693 for ; Thu, 9 Mar 2000 11:06:21 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6654F52D4; Thu, 9 Mar 2000 11:03:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DE4EE52D5; Thu, 9 Mar 2000 11:03:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8028852D4 for ; Thu, 9 Mar 2000 11:03:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 11:01:51 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Thu Mar 9 10:59:14 EST 2000 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA01084; Thu, 9 Mar 2000 10:01:48 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA22414; Thu, 9 Mar 2000 10:01:48 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA03285; Thu, 9 Mar 2000 10:01:47 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA03901; Thu, 9 Mar 2000 10:01:47 -0600 (CST) Message-Id: <200003091601.KAA03901@b04a24.exu.ericsson.se> Subject: Re: BYE request and CSeq value To: jmoloney@nortelnetworks.com (Joshua Moloney) Date: Thu, 9 Mar 2000 10:01:47 -0600 (CST) Cc: sip@lists.research.bell-labs.com In-Reply-To: <61ABD11436FED21192440000F81F3E36033118F5@nwcwi1a.europe.nortel.com> from "Joshua Moloney" at Mar 09, 2000 01:17:50 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >draft-ietf-mmusic-sip-new-00 says: >"A BYE request with a CSeq that is not higher should cause a 400 response to >be generated" (section 6.18). Be careful, though: the CSeq values are unique only in each direction. >How is it possible for a user agent to terminate a session when it has >somehow lost track of the sequence (CSeq value)? Perhaps CSeq: 4294967295 BYE ? I can't come up with a beleviable situation where you know that you're in a call but don't know what your own highest CSeq value is... An uncorralatable response (say, 200 response to an INVITE request that we don't remember making) will contain what the far end's notion of our last CSeq value is. An uncorralatable request (as, an INVITE with a To tag that we don't regocnise) will receive a 481 response. If you are obtaining the information that you're in a call from some local source, that same source should also contain the most recent local CSeq value. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 11:09:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21967 for ; Thu, 9 Mar 2000 11:09:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id ED86A52D5; Thu, 9 Mar 2000 11:05:41 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0FB8C52DA; Thu, 9 Mar 2000 11:05:39 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DB7B952D5 for ; Thu, 9 Mar 2000 11:05:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 11:04:07 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Thu Mar 9 11:01:31 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA18700; Thu, 9 Mar 2000 11:04:04 -0500 (EST) Message-ID: <38C7CB74.120E3533@cisco.com> Date: Thu, 09 Mar 2000 11:04:04 -0500 From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Cc: byerly@cisco.com Subject: How to put a Kerberos ticket in SIP messages? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi guys, I'm trying to understand how best to place a Kerberos (v5) ticket in SIP messages (i.e. either in SIP request or SIP response). (If someone already has such as draft, please forward me a copy.) I can think of two possible approaches: 1) Put it in a SIP header: 2) Put it in the SDP other ideas? 1) Thoughts on putting it in a header So, a Kerberos ticket is ASN.1 DER encoded. Is there any reason we couldn't just stick the binary representation of the ASN.1 DER encoded object in a header? Something like: ticket=fj7d543ghklc8654f7... (Yes, you're right, that's not a real ticket). So, I'm leaning towards a more generic header name like: Service-Authorization=[service name], [authorization-type], encoding=[encoding-type], ticket={octet string} authorization-type=kerberos5 encoding=octet-string b) Thoughts on putting it in the SDP Since a Kerberos ticket is ASN.1 DER encoded, it occurs to me that we'd need a email-safe version of the Kerberos ticket if we were to place it in the SDP. Can anyone point me to an existing draft/rfc which converts a Kerberos key to an email-safe version. I guess a draft on converting an arbitrary octet-string to an email-safe version would be fine too. P.S. For fun, who has a suggestion for which SDP abbreviation should be used for a Kerberos ticket? (It appears all the obvious ones are taken). taken: a, b, c, e, i, k, m, o, p, r, s, t, u, v, z remaining: f, g, h, j, l, n, q, w, x, y (Please correct me if some of these is already taken). Thanks for your help! Bryan Bryan J. Byerly byerly@cisco.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 11:25:50 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27460 for ; Thu, 9 Mar 2000 11:25:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 58D8852AB; Thu, 9 Mar 2000 11:23:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C15E452DA; Thu, 9 Mar 2000 11:23:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0A01C52AB for ; Thu, 9 Mar 2000 11:23:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 11:22:27 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Mar 9 11:19:51 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA01321; Thu, 9 Mar 2000 11:22:23 -0500 (EST) Message-ID: <38C7CFBC.42530A94@cs.columbia.edu> Date: Thu, 09 Mar 2000 11:22:20 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Byerly Cc: sip@lists.research.bell-labs.com Subject: Re: How to put a Kerberos ticket in SIP messages? References: <38C7CB74.120E3533@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Another option is just a SIP MIME bodypart. No binary-to-text translation needed there. Would be nice to spec this topic out. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 11:37:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01561 for ; Thu, 9 Mar 2000 11:37:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EB8F952C8; Thu, 9 Mar 2000 11:35:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6B99E52D6; Thu, 9 Mar 2000 11:35:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 588A252C8 for ; Thu, 9 Mar 2000 11:35:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 11:34:56 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Thu Mar 9 11:32:20 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA20963; Thu, 9 Mar 2000 11:34:53 -0500 (EST) Message-ID: <38C7D2AD.D1A94FC3@cisco.com> Date: Thu, 09 Mar 2000 11:34:53 -0500 From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Cc: Bryan Byerly Subject: Why do we need another header? Re: How to put a Kerberos ticket in SIP messages? References: <38C7CB74.120E3533@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit So I expect a few people to come back and ask why not reuse an existing header. I'm trying to achieve a flow where a SIP proxy hands back a Kerberos ticket to a client. The client, in turn can use this ticket for authorization to receive a service. (Yes, alternatively the client could go get his own ticket (if he knew the IP address of the KDC and was an authorized Kerberos client), and this follows along with moving complexity out to the endpoints. However, I'm trying to initially simplify things for dumber, less complex SIP clients. (and yes, I agree that SIP clients could eventually go get their own tickets)). Let's go through the list of existing headers and why we can't use them: 401 WWW-Authenticate: header and Authorization: header Using 401's WWW-Authenticate: header and the Authorization: header are used for end-to-end authorization. So, using WWW-Authenticate is not appropriate for passing back a Kerberos ticket. 407's Proxy-Authenticate: header and Proxy-Authorization: header Using 407's Proxy-Authenticate: header and the Proxy-Authorization: header are used to authorize a SIP client to transit through a SIP proxy. Proxy-Authorization: is specified by a SIP client to provide credentials such that he will be authorized by the SIP proxy. So, I don't think its appropriate to overload Proxy-Authorization: to mean "here's an authorization that the SIP proxy is passing to the SIP client". Response-Key: This header is used by a client to specify a key which it requests the called user agent should use to encrypt a response. So, its not appropriate to use this header to pass a ticket. Thanks again for your help and suggestions! Bryan Bryan J. Byerly byerly@cisco.com Bryan Byerly wrote: > Hi guys, > > I'm trying to understand how best to place a Kerberos (v5) ticket in > SIP messages (i.e. either in SIP request or SIP response). > (If someone already has such as draft, please forward me a copy.) > > I can think of two possible approaches: > 1) Put it in a SIP header: > 2) Put it in the SDP > other ideas? > > 1) Thoughts on putting it in a header > So, a Kerberos ticket is ASN.1 DER encoded. Is there any reason we > couldn't just stick the binary representation of the ASN.1 DER encoded > object in a header? > Something like: > ticket=fj7d543ghklc8654f7... > (Yes, you're right, that's not a real ticket). > > So, I'm leaning towards a more generic header name like: > Service-Authorization=[service name], [authorization-type], > encoding=[encoding-type], ticket={octet string} > authorization-type=kerberos5 > encoding=octet-string > > b) Thoughts on putting it in the SDP > > Since a Kerberos ticket is ASN.1 DER encoded, it occurs to me that we'd > need a email-safe version of the Kerberos ticket if we were to place it > in the SDP. > > Can anyone point me to an existing draft/rfc which converts a Kerberos > key to an email-safe version. I guess a draft on converting an > arbitrary octet-string to an email-safe version would be fine too. > > P.S. > For fun, who has a suggestion for which SDP abbreviation should be used > for a Kerberos ticket? (It appears all the obvious ones are taken). > taken: a, b, c, e, i, k, m, o, p, r, s, t, u, v, z > remaining: f, g, h, j, l, n, q, w, x, y (Please correct me if some > of these is already taken). > > Thanks for your help! > > Bryan > > Bryan J. Byerly > byerly@cisco.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 14:28:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25646 for ; Thu, 9 Mar 2000 14:28:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E8BFD52AB; Thu, 9 Mar 2000 14:25:29 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2E51052D6; Thu, 9 Mar 2000 14:25:28 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 65CB952AB for ; Thu, 9 Mar 2000 14:25:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 14:23:38 EST 2000 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by dusty; Thu Mar 9 14:21:03 EST 2000 Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA23318; Thu, 9 Mar 2000 11:23:36 -0800 (PST) Received: from dbuster-pc.cisco.com (rtp-pv55-dhcp-216.cisco.com [161.44.55.216]) by imop.cisco.com (Mirapoint) with SMTP id AAY16299; Thu, 9 Mar 2000 11:21:55 -0800 (PST) Message-Id: <200003091921.AAY16299@imop.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 09 Mar 2000 14:24:48 -0500 To: Jonathan Rosenberg From: Rohan Mahy Subject: Re: Provisional Response Draft Cc: sip@lists.research.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk At 01:28 PM 3/8/2000 -0500, you wrote: > > >Anders Kristensen wrote: >> >> "K. K. Ramakrishnan" wrote: >> > >> > I also appreciate the need to not have special casing for methods - >> > but is this extra messaging coming about because we chose to >> > have the PRACK as a "method"? On the issue of backwards compatibility, >> > couldn't we say that proxies shouldn't be creating transaction state >> > for things it doesn't understand? >> >> This proposal is itself not backwards compatible. Also, it doesn't seem >> quite right - it would mean, for example, that proxies cannot fork on >> requests they do not know. This seems like a big limitation. > >I agree completely here with Anders. The spec clearly defines handling >for unknown requests as if they were BYE. Hi, Actually, SIP 2.0 says, "Methods that are not supported by a proxy or redirect server are treated by that server as if they were an OPTIONS method and forwarded accordingly." (bottom of Page 27) Section 4.2.3 (The OPTIONS Method) goes on to say that user agents MAY respond to OPTIONS. I would infer from this (and a quick skim of Section 12) that there is no requirement for a proxy to respond to a method it doesn't understand. Is there still any compelling reason to require the 200 OK after PRACK? thanks, -rohan >As one of the design principles of SIP, we've really tried to make it a >fairly general purpose protocol. Many of the features and capabilities >have broad applicability and usage. Often, the result of this kind of a >decision is a tradeoff- messages are a little bigger, or more >information is sent, when its not always needed. I'd really like to keep >with that design philosophy. Having special case methods to cover every >new case, and requiring tons of Proxy-Requires to make it all work, ends >up resulting in a tangled mess of a protocol that doesn't interoperate. >Please, lets stick with the request-response model for all new methods. > >-Jonathan R. > >-- >Jonathan D. Rosenberg 200 Executive Drive >Chief Scientist Suite 120 >dynamicsoft West Orange, NJ 07052 >jdrosen@dynamicsoft.com FAX: (732) 741-4778 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >http://www.dynamicsoft.com > From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 14:31:22 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26477 for ; Thu, 9 Mar 2000 14:31:21 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B795D52B6; Thu, 9 Mar 2000 14:25:48 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D0D3552DA; Thu, 9 Mar 2000 14:25:47 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 05EB352B6 for ; Thu, 9 Mar 2000 14:25:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 14:23:31 EST 2000 Received: from sj-mailhub-3.cisco.com ([171.68.224.215]) by dusty; Thu Mar 9 14:20:55 EST 2000 Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA08657; Thu, 9 Mar 2000 11:48:02 -0800 (PST) Received: from dbuster-pc.cisco.com (rtp-pv55-dhcp-216.cisco.com [161.44.55.216]) by imop.cisco.com (Mirapoint) with SMTP id AAY16290; Thu, 9 Mar 2000 11:21:34 -0800 (PST) Message-Id: <200003091921.AAY16290@imop.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 09 Mar 2000 14:24:27 -0500 To: Alan Johnston From: Rohan Mahy Subject: Re: I-D ACTION:draft-ietf-sip-call-flows-00.txt Cc: sip@lists.research.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, I think messages F7 and F8 (183 responses) on Page 79 need the "Session: Media" header. Also, shouldn't F13 be after F14 (both PRACKs), and F15 be after F16 (200s for the PRACKs) on Page 84? thanks, -rohan At 10:11 AM 3/8/2000 -0600, you wrote: >This is the second draft of the Call Flows document (first draft was titled >draft-johnston-sip-call-flows-00.txt before it was accepted as a working group >draft). > >The major changes from the first draft are: > > - Converted all figures to ASCII art. > - Incorporated "SIP Telephony Service Examples with Call Flows" (Sparks et al), > draft-sparks-sip-service-examples-00, and also SIP Test Messages from the 2nd > Bakeoff (Rosenberg and Schulzrinne) into the document. > - Fixed assorted typos. > - Made references to ISUP explicitly ANSI and added some comments > on ITU and ETSI. > - Fixed CANCEL mistakes (use of tags, end to end acknowledgments, etc.) > - Added unique Authentication headers for each message. > - Added Reliable Provisional Responses (PRACK) to scenario 4.1.2 for > 183 Session Progress > - Added simple SIP to SIP call without proxies 3.1.1 > - Fixed "phone-context" and phone number handling in SIP URLs > >Any comments on the draft are greatly appreciated. > >Thanks to all the authors and the Call Flows Design Team. > >Alan Johnston >MCI WorldCom > >Internet-Drafts@ietf.org wrote: >> >> 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 Telephony Call Flow Examples >> Author(s) : A. Johnston, S. Donovan, R. Sparks,C. Cunningham, >> K. Summers, D. Willis, J. Rosenberg, H. Schulzrinne, >> Filename : draft-ietf-sip-call-flows-00.txt >> Pages : 268 >> Date : 06-Mar-00 >> >> This document gives examples of SIP (Session Initiation Protocol) >> call flows for IP telephony and service examples. Elements in these >> call flows include SIP User Agents and Clients, SIP Proxy and >> Redirect Servers, and Gateways to the PSTN (Public Switch Telephone >> Network). IP telephony scenarios include SIP Registration, SIP to >> SIP calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway >> via SIP. Call flow diagrams and message details are shown. PSTN >> telephony protocols are illustrated using ISDN (Integrated Services >> Digital Network), ANSI ISUP (ISDN User Part), and FGB (Feature Group >> B) circuit associated signaling. PSTN calls are illustrated using >> global telephone numbers from the PSTN and private extensions served >> on by a PBX (Private Branch Exchange). Telephony service examples >> illustrated with call flows include call hold, transfer, forwarding, >> screening, and Find-Me. Example SIP messages used for testing during >> SIP 'bakeoff' events include SIP 'torture test' messages, and >> messages with invalid parameters, methods, and tags. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-00.txt >> >> 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-call-flows-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-call-flows-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. >> >> ---------------------------------------------------------------------------- ---- >> Content-Type: text/plain >> Content-ID: <20000306120723.I-D@ietf.org> > From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 14:57:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04678 for ; Thu, 9 Mar 2000 14:57:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8408352BB; Thu, 9 Mar 2000 14:55:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E949252C8; Thu, 9 Mar 2000 14:55:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AB65D52BB for ; Thu, 9 Mar 2000 14:55:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 14:54:55 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Thu Mar 9 14:52:18 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id 285E86EE; Thu, 9 Mar 2000 11:54:51 -0800 (PST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA05642; Thu, 9 Mar 2000 19:54:02 GMT Message-ID: <38C80174.86879C62@hplb.hpl.hp.com> Date: Thu, 09 Mar 2000 19:54:28 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: Jonathan Rosenberg , sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft References: <200003091921.AAY16299@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > At 01:28 PM 3/8/2000 -0500, you wrote: > > > > > >Anders Kristensen wrote: > >> > >> "K. K. Ramakrishnan" wrote: > >> > > >> > I also appreciate the need to not have special casing for methods - > >> > but is this extra messaging coming about because we chose to > >> > have the PRACK as a "method"? On the issue of backwards compatibility, > >> > couldn't we say that proxies shouldn't be creating transaction state > >> > for things it doesn't understand? > >> > >> This proposal is itself not backwards compatible. Also, it doesn't seem > >> quite right - it would mean, for example, that proxies cannot fork on > >> requests they do not know. This seems like a big limitation. > > > >I agree completely here with Anders. The spec clearly defines handling > >for unknown requests as if they were BYE. > > Hi, > > Actually, SIP 2.0 says, "Methods that are not supported by a proxy or > redirect server are treated by that server as if they were an OPTIONS > method and forwarded accordingly." (bottom of Page 27) > > Section 4.2.3 (The OPTIONS Method) goes on to say that user agents MAY > respond to OPTIONS. No, that's not what it says. It says UAs MUST respond to OPTIONS. The MAY in section 4.2.3 has to do with what information goes into the response and whether the status code is the same as what would heve been returned had the request been an INVITE. > I would infer from this (and a quick skim of Section > 12) that there is no requirement for a proxy to respond to a method it > doesn't understand. That's not right. UAs must always respond to requests (unless they can't because the request is too buggy - e.g. without Via headers or whatever). > > Is there still any compelling reason to require the 200 OK after PRACK? > > thanks, > -rohan > -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 15:07:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07324 for ; Thu, 9 Mar 2000 15:07:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 695FC52C8; Thu, 9 Mar 2000 15:05:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D479F52D4; Thu, 9 Mar 2000 15:05:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F198F52C8 for ; Thu, 9 Mar 2000 15:05:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 15:03:12 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Mar 9 15:00:36 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA00182; Thu, 9 Mar 2000 15:03:20 -0500 (EST) Message-ID: <38C804DD.E5C0B597@dynamicsoft.com> Date: Thu, 09 Mar 2000 15:09:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft References: <200003091921.AAY16299@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Section 4.2.3 (The OPTIONS Method) goes on to say that user agents MAY > respond to OPTIONS. I would infer from this (and a quick skim of Section > 12) that there is no requirement for a proxy to respond to a method it > doesn't understand. > > Is there still any compelling reason to require the 200 OK after PRACK? Well, perhaps you should read the rest of the sentence. There are words after "MAY respond to this request". Lets be specific here. This section says: > The server is being queried as to its capabilities. A server that > believes it can contact the user, such as a user agent where the user > is logged in and has been recently active, MAY respond to this > request with a capability set. A called user agent MAY return a > status reflecting how it would have responded to an invitation, e.g., > > > > > Handley, et al. Standards Track [Page 29] > > RFC 2543 SIP: Session Initiation Protocol March 1999 > > > 600 (Busy). Such a server SHOULD return an Allow header field > indicating the methods that it supports. Proxy and redirect servers > simply forward the request without indicating their capabilities. > > This method MUST be supported by SIP proxy, redirect and user agent > servers, registrars and clients. That is it MAY respond with a capability set, or MAY respond with a status reflecting how it would have responded to the invitation. The MAY is a choice among how the response is formulated, NOT on whether a response is sent. All requests are responded to. period. By not having the 200 OK to PRACK, we break the transactional model of the protocol. This means proxies and UAs have all this extra state laying around. It means spurious CANCELs and responses might get sent. It means we probably need a Proxy-Require, and I really don't want to do that, because it means compatibility is broken. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 15:40:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15994 for ; Thu, 9 Mar 2000 15:40:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2AB5752D5; Thu, 9 Mar 2000 15:37:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 876A952D6; Thu, 9 Mar 2000 15:37:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E4B7F52D5 for ; Thu, 9 Mar 2000 15:37:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 15:36:23 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Thu Mar 9 15:33:42 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FR6006KI989CW@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 9 Mar 2000 20:36:11 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id UAA29130; Thu, 09 Mar 2000 20:36:42 +0000 (GMT) Received: from wcom.com ([166.33.132.111]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with ESMTP id <20000309203608.ICFR613@wcom.com>; Thu, 09 Mar 2000 20:36:08 +0000 Date: Thu, 09 Mar 2000 14:37:12 -0600 From: Alan Johnston Subject: Re: I-D ACTION:draft-ietf-sip-call-flows-00.txt To: Rohan Mahy Cc: sip@lists.research.bell-labs.com Message-id: <38C80B78.50A81E94@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <200003091921.AAY16290@imop.cisco.com> Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Rohan, You are correct - the Session:Media header is missing from all 183 responses in the document. That will be fixed - thanks for pointing this out. I think the sequence of PRACKs and 200 OKs in scenario 4.1.2 (page 84) is correct. PRACK is an end-to-end not hop-by-hop method (see Section 3 of draft-ietf-sip-100rel), so the 200 OK response to it is generated by GW 1 and forwarded by Proxy 1. This is why there is no requirement that proxies support the reliable response feature, but both User Agents must support it. Thanks for your comments! Alan. Rohan Mahy wrote: > > Hi, > > I think messages F7 and F8 (183 responses) on Page 79 need the "Session: > Media" header. > > Also, shouldn't F13 be after F14 (both PRACKs), and F15 be after F16 (200s > for the PRACKs) on Page 84? > > thanks, > -rohan > > At 10:11 AM 3/8/2000 -0600, you wrote: > >This is the second draft of the Call Flows document (first draft was titled > >draft-johnston-sip-call-flows-00.txt before it was accepted as a working > group > >draft). > > > >The major changes from the first draft are: > > > > - Converted all figures to ASCII art. > > - Incorporated "SIP Telephony Service Examples with Call Flows" (Sparks > et al), > > draft-sparks-sip-service-examples-00, and also SIP Test Messages from > the 2nd > > Bakeoff (Rosenberg and Schulzrinne) into the document. > > - Fixed assorted typos. > > - Made references to ISUP explicitly ANSI and added some comments > > on ITU and ETSI. > > - Fixed CANCEL mistakes (use of tags, end to end acknowledgments, etc.) > > - Added unique Authentication headers for each message. > > - Added Reliable Provisional Responses (PRACK) to scenario 4.1.2 for > > 183 Session Progress > > - Added simple SIP to SIP call without proxies 3.1.1 > > - Fixed "phone-context" and phone number handling in SIP URLs > > > >Any comments on the draft are greatly appreciated. > > > >Thanks to all the authors and the Call Flows Design Team. > > > >Alan Johnston > >MCI WorldCom > > > >Internet-Drafts@ietf.org wrote: > >> > >> 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 Telephony Call Flow Examples > >> Author(s) : A. Johnston, S. Donovan, R. Sparks,C. Cunningham, > >> K. Summers, D. Willis, J. Rosenberg, H. > Schulzrinne, > >> Filename : draft-ietf-sip-call-flows-00.txt > >> Pages : 268 > >> Date : 06-Mar-00 > >> > >> This document gives examples of SIP (Session Initiation Protocol) > >> call flows for IP telephony and service examples. Elements in these > >> call flows include SIP User Agents and Clients, SIP Proxy and > >> Redirect Servers, and Gateways to the PSTN (Public Switch Telephone > >> Network). IP telephony scenarios include SIP Registration, SIP to > >> SIP calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway > >> via SIP. Call flow diagrams and message details are shown. PSTN > >> telephony protocols are illustrated using ISDN (Integrated Services > >> Digital Network), ANSI ISUP (ISDN User Part), and FGB (Feature Group > >> B) circuit associated signaling. PSTN calls are illustrated using > >> global telephone numbers from the PSTN and private extensions served > >> on by a PBX (Private Branch Exchange). Telephony service examples > >> illustrated with call flows include call hold, transfer, forwarding, > >> screening, and Find-Me. Example SIP messages used for testing during > >> SIP 'bakeoff' events include SIP 'torture test' messages, and > >> messages with invalid parameters, methods, and tags. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-00.txt > >> > >> 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-call-flows-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-call-flows-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. > >> > >> > ---------------------------------------------------------------------------- > ---- > >> Content-Type: text/plain > >> Content-ID: <20000306120723.I-D@ietf.org> > > From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 15:58:10 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20074 for ; Thu, 9 Mar 2000 15:58:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4830E52D6; Thu, 9 Mar 2000 15:55:37 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A79C352DA; Thu, 9 Mar 2000 15:55:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 902D752D6 for ; Thu, 9 Mar 2000 15:55:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 9 15:53:35 EST 2000 Received: from ott-nw1.ss8.ca ([209.87.234.122]) by dusty; Thu Mar 9 15:50:59 EST 2000 Received: from engineer ([192.168.1.168]) by ott-nw1.ss8.ca (8.9.3/8.9.3) with SMTP id PAA28726; Thu, 9 Mar 2000 15:49:02 -0500 From: "Dave Walker" To: "Sip (E-mail)" , "ITU-T Study Group 16 (E-mail)" , "Sip-H323 (E-mail)" Subject: FW: 47th IETF: SIP323 BOF Date: Thu, 9 Mar 2000 15:52:48 -0500 Message-ID: <00a001bf8a09$6e3cf290$a801a8c0@domain01> 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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit For those who may have missed it, here is the official announcement of the BOF. Dave Walker SS8 Networks Ottawa, Canada -----Original Message----- From: mbeaulie@cnri.reston.va.us [mailto:mbeaulie@cnri.reston.va.us]On Behalf Of ietf-secretariat@ietf.org Subject: 47th IETF: SIP323 BOF SIP and H.323 Interworking BOF (sip323) Monday, March 27 at 1300-1500 ============================= CHAIRS: Joon Maeng Dave Walker DESCRIPTION: There are two competing standards in the industry for establishing and managing real-time interactive media communications over IP. One is the proposed IETF standard, Session Initiation Protocol (RFC 2543), and the other is the ITU recommendation, H.323. Although they use the same protocol (RTP) for media streaming, they cannot establish calls between them. In the absence of any formal interoperability standards, many vendors are beginning to develop proprietary application gateways for interworking between SIP and H.323. In order to provide interoperability between the two standards, it is urgent to define a common interworking specifications for the industry. The recognition of the need for this interworking specification has lead to calls for its development from both manufacturers and service providers, individually and through industry consortia (such as IMTC) and other bodies concerned with interoperability (such as ETSI). In this BOF, we are going to discuss SIP and H.323 interworking issues, execution plans and the scope of the work. AGENDA: - Do we need SIP-H.323 interworking? - Coordination with other groups? - Scope of interworking - Outcome of the work? - Suggestions? Helpful reading: - draft-singh-sip-h323-00.txt - SIP: Session Initiation Protocol (RFC 2543) - SDP: Session Description Protocol (RFC 2327) - ITU recommendations: H.323, H.225.0, H.245 From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 17:38:12 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19473 for ; Thu, 9 Mar 2000 17:38:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 839F352AB; Thu, 9 Mar 2000 17:35:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EDD3E52B6; Thu, 9 Mar 2000 17:35:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F40D752AB for ; Thu, 9 Mar 2000 17:35:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 17:33:56 EST 2000 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by dusty; Thu Mar 9 17:31:20 EST 2000 Received: from fokus.gmd.de (jobe [193.175.132.219]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id XAA03011; Thu, 9 Mar 2000 23:32:45 +0100 (MET) Message-ID: <38C826CE.A061C6F0@fokus.gmd.de> Date: Thu, 09 Mar 2000 23:33:50 +0100 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com, foeckel@fokus.gmd.de Subject: Re: firewall and NAT I-D available References: <38B38A82.E9D934CD@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan, draft-rosenberg-sip-firewalls is a very useful I-D that covered a big gap successfully. Some points follow that I have discussed with my colleagues recently. (The conclusion is that a kind of firewall control protocol is needed. Initial requirements are described in a separate I-D.) 1) You suggest using SOCKS (Section 5) as a possible alternative for "Firewall Control Protocol" (FCP). I am not sure SOCKS will help even without NAT. The discussed scheme looks like this:A packet filter implements 'default-deny' policy which explicitly permits traffic from and to SIP Proxy (ALG in generic terms). The SIP Proxy is in charge of opening pinholes in the packet filters during a SIP session. SIP SIP +---------+_____________ | ________|SIP Proxy| \ | / +---------+.. +----+---------------+ | : | | | : FCP +-----+------------+ | | :...........| FCP | Filtering | | | FTP +---------+.............| unit| Rules Table| | | _____|FTP Proxy|_____________+-----+------------+ | | / +---------+ | Packet Filter | | | -----| | +-----------+ / +----+---------------+ +-----------+| data streams / | +-----------+||----------------/ | |end-devices|| (RTP, ftp-data, etc.) | +-----------+ | | Inside | Outside With SOCKS, there is a UDP relayer which is most likely colocated with the packet filter to avoid introducing an additional hop along the data path. Then, the SIP Proxy needs to instruct the UDP relayer to receive incoming media streams. Unfortunately, SOCKS V5 does not allow to bind to publicly available *UDP* ports and receive at it. (The same problem applies if the end devices communicate with SOCKS server on their own.) Some documentation at www.socks5.com claims this is/will be fixed in V6. You could fix it by issuing a "UDP ASSOCIATE" command that would permit streams going to receivers address. This would possibly require the sender to be SOCKS-aware and encapsulate UDP packets in SOCKS wrappers; at least this is how I understand RFC 1928 saying "Each UDP datagram carries a UDP request header with it." I also guess, that even if SDP included sender's port number there would be no way to communicate them to SOCKS server. 2) The scheme above implies many filtering rules, at least compared to numbers common today. This may have performance implications. I would suggest including a "performance issues" section which states this problem. Briefly: too may rules->rule lookup computationaly expensive->increased packet latency. Algorithm allowing for fast lookup in big frequently changing flow tables are needed. These issues have been researched intensively, for example in: [1] A. Feldmann, S. Muthukrishnann: Tradeoffs for Packet Classification. In Proc. IEEE INFOCOM 2000, 2000. [2] V. Srinivasan, S. Suri, G. Varghese: PAcket Classification Using Tuple Space Search. In Proc. ACM SIGCOMM '99, 1999. [3] P. Gupta, N. McKeown: Packet Classification on Multiple Fields. In Proc. ACM SIGCOMM '99, 1999. 3) I guess it would be useful to say explicitly that a SIP proxy controlling a firewall needs to keep state during the entire session in order to be able to close appropriate pinholes on session termination. (This probably belongs to the last paragraph in Section 5, if I did not overlook it somewhere else.) 4) My understanding of Section 6.6 is you assume hard-state filtering rules in packet filters and tearing them down by SIP proxies. I would say that the expiry timeout should tick where the state resides. The packet filter could maintain timeouts on its own, possibly giving ALGs chance to set up the expiration time, because ALGs understand best how long period is appropriate to specific applications. SIP proxy may then simply translate SIP keep-alive-messages into filtering-rule-keep-alive-messages. It works in case of UA as well es proxy (which is stateful, see point 3) failure. 5) Summary: there is no existing applicable protocol for firewall control. This protocol is needed to allow ALGs to reside out of packet filters. Which is, IMHO, desirable since it allows to reuse existing logic sitting in ALGs (SIP proxies) and relieves *packet* filters from performing application filtering. We need to summarize requirements for firewall control protocol and see if there is an existing protocol we could reuse (e.g. extended SOCKS, or SNMP with a "packet filter MIB" or whatever). I made an attempt to capture the basic requirements and submitted it as draft-kuthan-fcp-00.txt. Until it appears in IETF directories it is available at http://www.fokus.gmd.de/research/cc/glone/employees/jiri.kuthan/private/draft-kuthan-fcp-00.txt Unfortunately, I will be off-line and not able to join discussion before March 21st. Jiri Jonathan Rosenberg wrote: > > Folks, > > Some colleagues and I have written and Internet Draft on getting SIP > through firewalls and NATs. It discusess the various configurations and > problems, and describes in detail the processing required to get things > working. The draft should appear in the archives shortly. Until it does, > you can pick up a copy at: > > http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-firewalls-00.txt > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- Jiri Kuthan Phone: +(49) / 30 - 3463 7 271 GMD FOKUS Fax : +(49) / 30 - 3463 8 271 Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de D-10589 Berlin, Germany WWW : http://www.fokus.gmd.de/usr/kuthan From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 19:36:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23528 for ; Thu, 9 Mar 2000 19:36:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 57DC552B6; Thu, 9 Mar 2000 19:33:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BD14852C4; Thu, 9 Mar 2000 19:33:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8762B52B6 for ; Thu, 9 Mar 2000 19:33:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 19:31:09 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Thu Mar 9 19:28:33 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id TAA16987; Thu, 9 Mar 2000 19:30:37 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38C84230.76F950D5@vovida.com> Date: Thu, 09 Mar 2000 16:30:40 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: Alan Johnston , sip@lists.research.bell-labs.com Subject: Re: I-D ACTION:draft-ietf-sip-call-flows-00.txt References: <200003091921.AAY16290@imop.cisco.com> Content-Type: multipart/alternative; boundary="------------9E5807058D8F34E7F5560941" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------9E5807058D8F34E7F5560941 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The draft is extremely useful. Thanks. I came across one inconsistency which is as below: In F18, for the BYE msg, should not the CSeq be 2 ? sunitha Rohan Mahy wrote: > Hi, > > I think messages F7 and F8 (183 responses) on Page 79 need the "Session: > Media" header. > > Also, shouldn't F13 be after F14 (both PRACKs), and F15 be after F16 (200s > for the PRACKs) on Page 84? > > thanks, > -rohan > > At 10:11 AM 3/8/2000 -0600, you wrote: > >This is the second draft of the Call Flows document (first draft was titled > >draft-johnston-sip-call-flows-00.txt before it was accepted as a working > group > >draft). > > > >The major changes from the first draft are: > > > > - Converted all figures to ASCII art. > > - Incorporated "SIP Telephony Service Examples with Call Flows" (Sparks > et al), > > draft-sparks-sip-service-examples-00, and also SIP Test Messages from > the 2nd > > Bakeoff (Rosenberg and Schulzrinne) into the document. > > - Fixed assorted typos. > > - Made references to ISUP explicitly ANSI and added some comments > > on ITU and ETSI. > > - Fixed CANCEL mistakes (use of tags, end to end acknowledgments, etc.) > > - Added unique Authentication headers for each message. > > - Added Reliable Provisional Responses (PRACK) to scenario 4.1.2 for > > 183 Session Progress > > - Added simple SIP to SIP call without proxies 3.1.1 > > - Fixed "phone-context" and phone number handling in SIP URLs > > > >Any comments on the draft are greatly appreciated. > > > >Thanks to all the authors and the Call Flows Design Team. > > > >Alan Johnston > >MCI WorldCom > > > >Internet-Drafts@ietf.org wrote: > >> > >> 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 Telephony Call Flow Examples > >> Author(s) : A. Johnston, S. Donovan, R. Sparks,C. Cunningham, > >> K. Summers, D. Willis, J. Rosenberg, H. > Schulzrinne, > >> Filename : draft-ietf-sip-call-flows-00.txt > >> Pages : 268 > >> Date : 06-Mar-00 > >> > >> This document gives examples of SIP (Session Initiation Protocol) > >> call flows for IP telephony and service examples. Elements in these > >> call flows include SIP User Agents and Clients, SIP Proxy and > >> Redirect Servers, and Gateways to the PSTN (Public Switch Telephone > >> Network). IP telephony scenarios include SIP Registration, SIP to > >> SIP calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway > >> via SIP. Call flow diagrams and message details are shown. PSTN > >> telephony protocols are illustrated using ISDN (Integrated Services > >> Digital Network), ANSI ISUP (ISDN User Part), and FGB (Feature Group > >> B) circuit associated signaling. PSTN calls are illustrated using > >> global telephone numbers from the PSTN and private extensions served > >> on by a PBX (Private Branch Exchange). Telephony service examples > >> illustrated with call flows include call hold, transfer, forwarding, > >> screening, and Find-Me. Example SIP messages used for testing during > >> SIP 'bakeoff' events include SIP 'torture test' messages, and > >> messages with invalid parameters, methods, and tags. > >> > >> A URL for this Internet-Draft is: > >> http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-00.txt > >> > >> 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-call-flows-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-call-flows-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. > >> > >> > ---------------------------------------------------------------------------- > ---- > >> Content-Type: text/plain > >> Content-ID: <20000306120723.I-D@ietf.org> > > -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------9E5807058D8F34E7F5560941 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit The draft is extremely useful. Thanks. I came across one inconsistency which is as below:

In F18, for the BYE msg, should not the CSeq be 2 ?

sunitha
 

Rohan Mahy wrote:

Hi,

I think messages F7 and F8 (183 responses) on Page 79 need the "Session:
Media" header.

Also, shouldn't F13 be after F14 (both PRACKs), and F15 be after F16 (200s
for the PRACKs) on Page 84?

thanks,
-rohan

At 10:11 AM 3/8/2000 -0600, you wrote:
>This is the second draft of the Call Flows document (first draft was titled
>draft-johnston-sip-call-flows-00.txt before it was accepted as a working
group
>draft).
>
>The major changes from the first draft are:
>
>       - Converted all figures to ASCII art.
>       - Incorporated "SIP Telephony Service Examples with Call Flows" (Sparks
et al),
>         draft-sparks-sip-service-examples-00, and also SIP Test Messages from
the 2nd
>         Bakeoff (Rosenberg and Schulzrinne) into the document.
>       - Fixed assorted typos.
>       - Made references to ISUP explicitly ANSI and added some comments
>         on ITU and ETSI.
>       - Fixed CANCEL mistakes (use of tags, end to end acknowledgments, etc.)
>       - Added unique Authentication headers for each message.
>       - Added Reliable Provisional Responses (PRACK) to scenario 4.1.2 for
>         183 Session Progress
>       - Added simple SIP to SIP call without proxies 3.1.1
>       - Fixed "phone-context" and phone number handling in SIP URLs
>
>Any comments on the draft are greatly appreciated.
>
>Thanks to all the authors and the Call Flows Design Team.
>
>Alan Johnston
>MCI WorldCom
>
>Internet-Drafts@ietf.org wrote:
>>
>> 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 Telephony Call Flow Examples
>>         Author(s)       : A. Johnston, S. Donovan, R. Sparks,C. Cunningham,
>>                           K. Summers,  D. Willis, J. Rosenberg,  H.
Schulzrinne,
>>         Filename        : draft-ietf-sip-call-flows-00.txt
>>         Pages           : 268
>>         Date            : 06-Mar-00
>>
>> This document gives examples of SIP (Session Initiation Protocol)
>> call flows for IP telephony and service examples.  Elements in these
>> call flows include SIP User Agents and Clients, SIP Proxy and
>> Redirect Servers, and Gateways to the PSTN (Public Switch Telephone
>> Network).  IP telephony scenarios include SIP Registration, SIP to
>> SIP calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway
>> via SIP.  Call flow diagrams and message details are shown.  PSTN
>> telephony protocols are illustrated using ISDN (Integrated Services
>> Digital Network), ANSI ISUP (ISDN User Part), and FGB (Feature Group
>> B) circuit associated signaling.  PSTN calls are illustrated using
>> global telephone numbers from the PSTN and private extensions served
>> on by a PBX (Private Branch Exchange).  Telephony service examples
>> illustrated with call flows include call hold, transfer, forwarding,
>> screening, and Find-Me.  Example SIP messages used for testing during
>> SIP 'bakeoff' events include SIP 'torture test' messages, and
>> messages with invalid parameters, methods, and tags.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-00.txt
>>
>> 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-call-flows-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-call-flows-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.
>>
>>
----------------------------------------------------------------------------
----
>> Content-Type: text/plain
>> Content-ID:     <20000306120723.I-D@ietf.org>
>

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374
  --------------9E5807058D8F34E7F5560941-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Mar 9 21:16:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23109 for ; Thu, 9 Mar 2000 21:16:07 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 56BBE52BB; Thu, 9 Mar 2000 21:13:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BC6A152AB; Thu, 9 Mar 2000 21:13:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1A15152BB for ; Thu, 9 Mar 2000 21:13:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 9 21:12:20 EST 2000 Received: from transnexus.com ([63.210.64.108]) by dusty; Thu Mar 9 21:09:44 EST 2000 Received: from notebook.transnexus.com by transnexus.com with SMTP (MDaemon.v2.8.7.0.R) for ; Thu, 09 Mar 2000 21:14:51 -0500 Message-Id: <4.3.2.20000309210050.00b34ef8@mail.transnexus.com> X-Sender: SThomas@mail.transnexus.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 09 Mar 2000 21:02:04 -0500 To: owner-sip-outgoing@lists.research.bell-labs.com From: Stephen Thomas Subject: Re: How to put a Kerberos ticket in SIP messages? Cc: Bryan Byerly , sip@lists.research.bell-labs.com In-Reply-To: <38C7CFBC.42530A94@cs.columbia.edu> References: <38C7CB74.120E3533@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-MDaemon-Deliver-To: sip@lists.research.bell-labs.com X-Return-Path: stephen.thomas@transnexus.com Reply-To: stephen.thomas@transnexus.com Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Indeed, see draft-thomas-mime-osp-token-00.txt At 11:22 AM 2000-03-09 -0500, Henning Schulzrinne wrote: >Another option is just a SIP MIME bodypart. No binary-to-text >translation needed there. Would be nice to spec this topic out. >-- >Henning Schulzrinne http://www.cs.columbia.edu/~hgs ____________________________________________________________________ Stephen Thomas +1 404 872 4887 TransNexus, Chief Technical Officer stephen.thomas@transnexus.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 02:10:16 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08574 for ; Fri, 10 Mar 2000 02:10:14 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4561452B6; Fri, 10 Mar 2000 02:07:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A18EB52BB; Fri, 10 Mar 2000 02:07:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 9C4DC52B6 for ; Fri, 10 Mar 2000 02:07:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 10 02:05:59 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Mar 10 02:03:23 EST 2000 Received: from dynamicsoft.com (2Cust56.tnt3.freehold.nj.da.uu.net [63.11.112.56]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA01116 for ; Fri, 10 Mar 2000 02:06:07 -0500 (EST) Message-ID: <38C8A036.7369939F@dynamicsoft.com> Date: Fri, 10 Mar 2000 02:11:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: New I-D available soon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I've just posted an individual Internet Draft which may be of interest. Its entitled "Guidelines for Authors of SIP Extensions". Its discusses issues that writers of SIP extensions should consider while developing them and writing them up. It also gives some guidance on what things make good SIP extensions, and what things do not. Until it appears in the archives, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-guidelines-00.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 02:31:13 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15351 for ; Fri, 10 Mar 2000 02:31:10 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8434C52BB; Fri, 10 Mar 2000 02:27:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D735E52C8; Fri, 10 Mar 2000 02:27:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F0F0B52BB for ; Fri, 10 Mar 2000 02:27:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 10 02:26:58 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Mar 10 02:24:22 EST 2000 Received: from dynamicsoft.com (2Cust56.tnt3.freehold.nj.da.uu.net [63.11.112.56]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA01129; Fri, 10 Mar 2000 02:27:07 -0500 (EST) Message-ID: <38C8A521.DBDCCC08@dynamicsoft.com> Date: Fri, 10 Mar 2000 02:32:49 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Subject: TRIP for gateway registrations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Every once in a while, the question comes up of why SIP REGISTER is not the right vehicle for allowing gateways to register phone prefixes with a proxy. I believe TRIP is far better for this purpose. As it turns out, a small subset of TRIP is needed to solve this problem, and yet its still interoperable with full blown TRIP. Hussein Salama and I have written an I-D that discusses this. Until it appears in the archives, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rs-trip-gw-00.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 06:32:30 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00639 for ; Fri, 10 Mar 2000 06:32:30 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 389A052C8; Fri, 10 Mar 2000 06:29:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 25BB752DA; Fri, 10 Mar 2000 06:29:34 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BEEFA52C8 for ; Fri, 10 Mar 2000 06:29:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 10 06:28:43 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Fri Mar 10 06:26:07 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28620; Fri, 10 Mar 2000 06:28:33 -0500 (EST) Message-Id: <200003101128.GAA28620@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt Date: Fri, 10 Mar 2000 06:28:33 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SIP Precedence mapping to MLPP Interworking Author(s) : J. Polk Filename : draft-polk-sip-mlpp-mapping-00.txt Pages : 10 Date : 09-Mar-00 This document describes an extension to the Session Initiation Protocol [1] for direct interworking and interoperability with TDM-based Multi-Level Precedence and Preemption [2] Service Capability networks. This document will further include details and similar mechanisms to evolve and/or replace existing TDM-based MLPP network topologies with SIP-based Voice Signaling topologies with no loss of capability. Al- though additional mobility and capabilities can easily be realized with this complete topology architecture implemented. The author believes these additional Prioritization and Preemption capabilities will have wider deployment benefits without direct connectivity to MLPP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-polk-sip-mlpp-mapping-00.txt 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-polk-sip-mlpp-mapping-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-polk-sip-mlpp-mapping-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: <20000309140057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-polk-sip-mlpp-mapping-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-polk-sip-mlpp-mapping-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309140057.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 06:37:15 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02365 for ; Fri, 10 Mar 2000 06:37:14 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9651D52DA; Fri, 10 Mar 2000 06:32:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 690CB52C4; Fri, 10 Mar 2000 06:32:17 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 891CC52C4 for ; Fri, 10 Mar 2000 06:31:13 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 10 06:30:48 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Fri Mar 10 06:28:12 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29724; Fri, 10 Mar 2000 06:30:46 -0500 (EST) Message-Id: <200003101130.GAA29724@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sip-callerprefs-01.txt Date: Fri, 10 Mar 2000 06:30:45 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --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 Caller Preferences and Callee Capabilities Author(s) : H. Schulzrinne, J. Rosenberg Filename : draft-ietf-sip-callerprefs-01.txt Pages : 22 Date : 09-Mar-00 This document describes a set of extensions to SIP which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which URIs a call gets proxied or redirected to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request headers, Accept-Contact, Reject-Contact and Request-Disposition, which specify the callers preferences. The extension also defines new parameters for the Contact header. These extra parameters are present in the Contact header in REGISTER requests, and are used to associated attributes with particular addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-01.txt 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-callerprefs-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-callerprefs-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000309140518.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-callerprefs-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-callerprefs-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309140518.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 06:40:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03241 for ; Fri, 10 Mar 2000 06:40:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C224852D5; Fri, 10 Mar 2000 06:32:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C942552D6; Fri, 10 Mar 2000 06:32:16 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 36BB452D5 for ; Fri, 10 Mar 2000 06:31:14 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 10 06:30:52 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Fri Mar 10 06:28:17 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29756; Fri, 10 Mar 2000 06:30:50 -0500 (EST) Message-Id: <200003101130.GAA29756@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sip-session-timer-01.txt Date: Fri, 10 Mar 2000 06:30:50 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --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 Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-01.txt Pages : 14 Date : 09-Mar-00 This document proposes an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE. The refresh allows both user agents and call stateful proxies to determine in the SIP session is still active. The extension defines a new general header, Session-Expires, which conveys the lifetime of the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-01.txt 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-session-timer-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-session-timer-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000309140530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309140530.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 06:42:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04073 for ; Fri, 10 Mar 2000 06:42:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A091252C4; Fri, 10 Mar 2000 06:34:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BFA6952DC; Fri, 10 Mar 2000 06:34:03 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 4B1D552DB for ; Fri, 10 Mar 2000 06:33:10 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 10 06:31:12 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Fri Mar 10 06:28:36 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29665; Fri, 10 Mar 2000 06:30:40 -0500 (EST) Message-Id: <200003101130.GAA29665@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sip-mib-00.txt Date: Fri, 10 Mar 2000 06:30:39 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --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 : Management Information Base for Session Invitation Protocol Author(s) : K. Lingle, J. Maeng, D. Walker Filename : draft-ietf-sip-mib-00.txt Pages : 71 Date : 09-Mar-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol(SIP) [17] devices, which include User Agent, Proxy server, Redirect server and Registrar. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-00.txt 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-mib-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-mib-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: <20000309140507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000309140507.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 10:15:34 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15209 for ; Fri, 10 Mar 2000 10:15:32 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BAF8452DC; Fri, 10 Mar 2000 10:06:54 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DBFBD52D6; Fri, 10 Mar 2000 10:06:53 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B05CA52B6 for ; Wed, 8 Mar 2000 23:13:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 8 23:12:45 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 8 23:09:58 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA21270; Thu, 9 Mar 2000 10:09:41 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525689D.001729F8 ; Thu, 9 Mar 2000 09:43:00 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Adam B. Roach" Cc: sip@lists.research.bell-labs.com Message-ID: <6525689D.0017280E.00@sampark.hss.hns.com> Date: Thu, 9 Mar 2000 09:42:55 +0530 Subject: Re: Two New Drafts Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, some questions: 1. The draft does not mention what happens when multiple SUBSCRIBE requests arrive from the same user. In REGISTER, they replace old ones if the SIP url is same and additive otherwise. However, in SUBSCRIBE, I think it would make sense to make it additive only, since the same SIP url can subscribe to multiple events using diff. subscription messages. Is this correct ? 2. What do I do when I want to send a subscription like: " I want to be notifed when user A sends me a voice mail for the next 3 hrs AND when user B sends me a voice mail for the next 2 hrs " Do I send two different SUBSCRIBEs like SUBSCRIBE ..... event: voice-mail Expires: <3hrs> Call-ID: XXXXXXX and SUBSCRIBE ..... event: voice-mail Expires: <2hrs> Call-ID: YYYYY Now in above, I feel the event header should be broken up more so I dont have to put in the entire event in one token only (although Im not sure how much of break up would satisfy everyone - maybe something like cp-params of Caller&Callee preferences ?) Maybe we could have event as token *(; value) where value = token | token "=" token where the first token mentions the primary service like "voice-mail", "terminal-free" etc and the second set of tokens to be a description about the primary event which the server supporting the event would understand. Then w could do: event: voice-mail;user="A" or something Further, If I wanted to sent multiple subscriptions as one ordered set (like I want to be notified of voicemails from A,B,C for a duration of 2,3,4 hrs) , then the only way I see it either break it up into 3 SUBSCRIBE (requiring then that I have 3 call ids to correlate) or that I do one request with 3 Event Headers and 3 Expires headers and do something like first Event matches first Expires - which again does not seem to be good. Would it make sense, then to define Event as minimally Event = 1#(eventid ; duration) event = token // Does it need to be broken ? duration = deltaseconds | SIP-Date 3. REGISTER with Exp : 0 I guess unregisters a user from the registrar (or certain contacts from the registrar) - however, subscribing to a notificaton service, imho, is different from registering for normal sip operations and hence I feel REGISTER should not be used to delete SUBSCRIBEs - I would wanyt to subscribe, unsubscribe from notifications often without wanting to touch my registration at all - hence I feel UNSUBSCRIBE is better that overloading REGISTER Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "Adam B. Roach" on 03/09/2000 02:45:52 AM To: sip@lists.research.bell-labs.com cc: Subject: Two New Drafts There are two new drafts on the IETF web site. The first one is an attempt at formalising a general, extensible event notification for SIP using SUBSCRIBE and NOTIFY. The second draft demonstrates an application of this event notification (using an auto-call-back service), along with callflows. --------------------------------------------------------------------------- Title: Event Notification in SIP Abstract: This document describes an extension to the Session Initiation Protocol (SIP) [1] . The purpose of this extension is to provide a generic and extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occured. Concrete uses of the mechanism described in this document may be standardized in the future. http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00. txt --------------------------------------------------------------------------- Title: Automatic Call Back Service in SIP Abstract: This document describes a proposed implementation of an Automatic Call Back (ACB) service using SIP. This service is somtimes refered to as "camp on extension," "call again," "automatic redial," and "automatic recall." http://search.ietf.org/internet-drafts/draft-roach-sip-acb-00.txt -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 10:22:35 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17014 for ; Fri, 10 Mar 2000 10:22:33 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 12AD852DD; Fri, 10 Mar 2000 10:07:29 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C9A6152DB; Fri, 10 Mar 2000 10:07:18 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 7322152AB for ; Thu, 9 Mar 2000 10:47:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 9 10:45:23 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Thu Mar 9 10:42:47 EST 2000 Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id JAA05035; Thu, 9 Mar 2000 09:45:17 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA04896; Thu, 9 Mar 2000 09:45:17 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA01852; Thu, 9 Mar 2000 09:45:16 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id JAA03797; Thu, 9 Mar 2000 09:45:15 -0600 (CST) Message-Id: <200003091545.JAA03797@b04a24.exu.ericsson.se> Subject: Re: Two New Drafts To: archow@hss.hns.com Date: Thu, 9 Mar 2000 09:45:15 -0600 (CST) Cc: sip@lists.research.bell-labs.com In-Reply-To: <6525689D.0017280E.00@sampark.hss.hns.com> from "archow@hss.hns.com" at Mar 09, 2000 09:42:55 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit archow@hss.hns.com writes: >The draft does not mention what happens when multiple SUBSCRIBE requests >arrive from the same user. In REGISTER, > they replace old ones if the SIP url is same and additive otherwise. >However, in SUBSCRIBE, I think it would make sense to make it additive >only, since the same SIP url can subscribe to multiple events using diff. >subscription messages. Is this correct ? That sounds good, except possibly for the same "call leg". I think the part that needs to be clarified is: if a user sends a SUBSCRIBE which has the same Call-ID, From, and To as a previous request, does it add events or override them? I'm leaning towards overrriding events, since there is no easy way to remove events otherwise. Note well that this wouldn't apply to other subscriptions with different Call-IDs, which would (of course) remain additive. I don't think it would be too onerous to require user agents to send a full list of events for each call-related subscription, since they're already having to maintain a tubload of state information about the call. Any comments on this from other people? >2. What do I do when I want to send a subscription like: > >" I want to be notifed when user A sends me a voice mail for the next 3 hrs >AND when user B sends me a voice mail for the next 2 hrs " ... >Maybe we could have event as token *(; value) where value = token | token >"=" token >where the first token mentions the primary service like "voice-mail", >"terminal-free" etc and the second set of tokens to be a description about >the primary event which the server supporting the event would understand. > >Then we could do: event: voice-mail;user="A" or something This certainly makes it more flexible. The ability to add parameters to a particular event type would save future extensions from having to worry about adding new headers. SUBSCRIBE ..... Call-ID: cf2-38c7bc98-0afe9af6-f@138.85.60.124 Event: voice-mail;from=sip:archow@hss.hns.com Expires: 7200 SUBSCRIBE ..... Call-ID: e24-38c7be4d-07027041-9@138.85.60.124 Event: voice-mail;from=sip:hgs@cs.columbia.edu Expires: 10800 (Incidentally, I like your example. I have recently had discussions with several different groups of people who wanted to know how one would go about, for example, having a light blink on your phone and/or have a distinctive dial tone when a message is waiting). >Further, If I wanted to sent multiple subscriptions as one ordered set >(like I want to be notified of voicemails from A,B,C for a duration of >2,3,4 hrs) , then the only way I see it either break it up into 3 SUBSCRIBE >(requiring then that I have 3 call ids to correlate) or that I do one >request with 3 Event Headers and 3 Expires headers and do something like >first Event matches first Expires - which again does not seem to be good. > >Would it make sense, then to define Event as minimally > >Event = 1#(eventid ; duration) >event = token // Does it need to be broken ? >duration = deltaseconds | SIP-Date I don't really like this. Beyond the problems with using commas for separators *and* having commas appear in the duration (if the SIP-Date format is used), I'm trying to keep it as congruent as possible with REGISTER, since the semantics for that are already well defined -- and code is already written to handle it. For the above situation, I'd propose that you either: a) send all three REGISTER messages, with different Call-IDs, in a single UDP packet, or b) send a single REGISTER for all three events with an expires of 2 hours. At the end of the 2 hours, re-SUBSCRIBE for just B and C (expires in one hour), and one hour later, re-SUBSCRIBE for just C. (A variation on this theme would be to subscribe for 4 hours, override it in 2, and then again one hour later; I prefer this method, since it eliminates the chances of missing events -- although it counts on the addition vs. replacement semantics I describe above). SUBSCRIBE ..... Call-ID: a26-38c7beba-470f1c26-0@138.85.60.124 Event: voice-mail;from=sip:archow@hss.hns.com, voice-mail;from=sip:hgs@cs.columbia.edu, voice-mail;from=sip:jdrosen@dynamicsoft.com Expires: 14400 Date: Thu, 09 Mar 2000 15:00:00 GMT SUBSCRIBE ..... Call-ID: a26-38c7beba-470f1c26-0@138.85.60.124 Event: voice-mail;from=sip:hgs@cs.columbia.edu, voice-mail;from=sip:jdrosen@dynamicsoft.com Expires: 7200 Date: Thu, 09 Mar 2000 17:00:00 GMT SUBSCRIBE ..... Call-ID: a26-38c7beba-470f1c26-0@138.85.60.124 Event: voice-mail;from=sip:jdrosen@dynamicsoft.com Expires: 3600 Date: Thu, 09 Mar 2000 18:00:00 GMT When thinking about this, also consider that the server may reduce the "Expires" header down to some uniform smaller value anyway. If you're going through the trouble of breaking it up into three separate Call-IDs, all of which get turned down to expire in one hour by the server, what are you gaining? >3. REGISTER with Exp : 0 I guess unregisters a user from the registrar (or >certain contacts from the registrar) - however, subscribing to >a notificaton service, imho, is different from registering for normal sip >operations and hence I feel REGISTER should not be used to >delete SUBSCRIBEs - I would wanyt to subscribe, unsubscribe from >notifications often without wanting to touch my registration at all - >hence I feel UNSUBSCRIBE is better that overloading REGISTER I must have been somewhat unclear. I am not proposing that one use REGISTER itself to cancel a subscription; merely that one use the same *mechanism*, with a SUBSCRIBE method. For example, let's say that I want to cancel the subscription(s) above. I could do so by sending: SUBSCRIBE ..... Call-ID: a26-38c7beba-470f1c26-0@138.85.60.124 Event: voice-mail Expires: 0 Date: Thu, 09 Mar 2000 15:30:00 GMT -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 10:29:36 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19041 for ; Fri, 10 Mar 2000 10:29:34 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8EC3552D6; Fri, 10 Mar 2000 10:11:27 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 495FD52E6; Fri, 10 Mar 2000 10:09:14 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id BADEC52C4 for ; Fri, 10 Mar 2000 03:55:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 10 03:53:18 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Fri Mar 10 03:50:36 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id OAA08576; Fri, 10 Mar 2000 14:49:48 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525689E.0030D832 ; Fri, 10 Mar 2000 14:23:30 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Adam B. Roach" Cc: archow@hss.hns.com, sip@lists.research.bell-labs.com Message-ID: <6525689E.0030D6CF.00@sampark.hss.hns.com> Date: Fri, 10 Mar 2000 14:23:26 +0530 Subject: Re: Two New Drafts Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, responses embedded and preceded by ARC> >The draft does not mention what happens when multiple SUBSCRIBE requests >arrive from the same user. In REGISTER, > they replace old ones if the SIP url is same and additive otherwise. >However, in SUBSCRIBE, I think it would make sense to make it additive >only, since the same SIP url can subscribe to multiple events using diff. >subscription messages. Is this correct ? That sounds good, except possibly for the same "call leg". I think the part that needs to be clarified is: if a user sends a SUBSCRIBE which has the same Call-ID, From, and To as a previous request, does it add events or override them? I'm leaning towards overrriding events, since there is no easy way to remove events otherwise. Note well that this wouldn't apply to other subscriptions with different Call-IDs, which would (of course) remain additive. ARC> Somehow, I feel Call-ID and suscription should not be tied together. This is primarily ARC> because callid is generated by a terminal and a user has no control over it. ARC> However, a subscription is for a user, not a terminal. so if I subscribe to a set of services ARC> today, if I travel tomorrow, I want to walk into a Cyber Cafe, log in using some applet based ARC> sip client that will generate a different Call-ID from my old desktop one an still be able to ARC> access my old subscription list and add/del from it without having to know the Call-Id - which ARC> in many cases, I never get to see as a user. ARC> but the moment the backend notifier works on Call-ID - then I would never be able to 'Add' to ARC> my list since Ill be using a different Call-ID in all probability, neither will I be able to ARC> somehow retrieve the old one, since match will never be true. ARC> This is why I feel subscription should not be linked to a call - id. (Incidentally, I like your example. I have recently had discussions with several different groups of people who wanted to know how one would go about, for example, having a light blink on your phone and/or have a distinctive dial tone when a message is waiting). ARC> Well, we actually had exactly the above requirement once, and we did it my adding ARC> an Event like field with more or less the same semantics as we discussed above. >Event = 1#(eventid ; duration) >event = token // Does it need to be broken ? >duration = deltaseconds | SIP-Date I don't really like this. Beyond the problems with using commas for separators *and* having commas appear in the duration (if the SIP-Date format is used), I'm trying to keep it as congruent as possible with REGISTER, since the semantics for that are already well defined -- and code is already written to handle it. For the above situation, I'd propose that you either: a) send all three REGISTER messages, with different Call-IDs, in a single UDP packet, or b) send a single REGISTER for all three events with an expires of 2 hours. At the end of the 2 hours, re-SUBSCRIBE for just B and C (expires in one hour), and one hour later, re-SUBSCRIBE for just C. (A variation on this theme would be to subscribe for 4 hours, override it in 2, and then again one hour later; I prefer this method, since it eliminates the chances of missing events -- although it counts on the addition vs. replacement semantics I describe above). ARC> I assume where ever you mentioned REGISTER above , you meant SUBSCRIBE ARC> Again, solution 1 is to me, a kind of loose workaround. And the other solutions ARC> force the client to maintain time differentiators actively since it must physically ARC> maniuplate subscriptions to implement the common requirement above. Rather, The ARC> Notifier is actually already implementing a timer list which can notify users ARC> based on differential time values maybe, so why force the client into maintain the ARC> differential list also ? To me it seems to be much cleaner for the client to specify ARC> it once, and forget about it, as the notifier server is there just to remind him anyway ARC> so why bog him down with keeping track of such requests ? ARC> The only -ve point seems to be parsing for commas (which is a non issue for good parsers) ARC> - but if that really is a problem, maybe we could work at a simpler expiry type ? ARC> However, I dont feel parsing should be the reason to adopt the alternate methods suggested ARC> above. What do you/others feel abt it ? I must have been somewhat unclear. I am not proposing that one use REGISTER itself to cancel a subscription; merely that one use the same *mechanism*, with a SUBSCRIBE method. For example, let's say that I want to cancel the subscription(s) above. I could do so by sending: ARC> Sorry, I misinterpreted, then. Seems fine to me. From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 13:12:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14107 for ; Fri, 10 Mar 2000 13:12:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AE6F652AB; Fri, 10 Mar 2000 13:09:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2A46252DB; Fri, 10 Mar 2000 13:09:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0790A52AB for ; Fri, 10 Mar 2000 13:09:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 10 13:07:24 EST 2000 Received: from kickme.cisco.com ([198.92.30.42]) by dusty; Fri Mar 10 13:04:47 EST 2000 Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA27957; Fri, 10 Mar 2000 09:55:20 -0800 (PST) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAY23631; Fri, 10 Mar 2000 10:05:25 -0800 (PST) Message-Id: <4.2.0.58.20000310091028.00cb23c0@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 10 Mar 2000 10:06:31 -0800 To: Jonathan Rosenberg , Anders Kristensen , kkrama@research.att.com From: Rohan Mahy Subject: Re: Provisional Response Draft Cc: sip@lists.research.bell-labs.com In-Reply-To: <38C804DD.E5C0B597@dynamicsoft.com> References: <200003091921.AAY16299@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, At 12:09 PM 3/9/00 , Jonathan Rosenberg wrote: >All requests are responded to. period. I never debated this. The user agents will always have an opportunity to respond. I agree with kkrama@research.att.com, that proxies shouldn't keep state for methods they don't understand. They can simply forward messages for these unknown methods on to the user agents or the next proxy. >By not having the 200 OK to PRACK, we break the transactional model of >the protocol. This means proxies and UAs have all this extra state >laying around. It means spurious CANCELs and responses might get sent. >It means we probably need a Proxy-Require, and I really don't want to do >that, because it means compatibility is broken. In my interpretation, the spec does not explicitly _require_ proxies to keep state for methods that they don't understand. The spec does not explicitly _prohibit_ proxies from keeping state for methods they don't understand. So what I hear Jonathan saying is that because some proxies MIGHT keep state for new methods, then we need 200 OK, so that we don't break them. Correct? I am personally curious how many proxies would break. Also, I hear Jonathan saying that new methods should be processed in the same way, and that this encourages simplicity. Aside from the comment above, is there another motivation for this? thanks, -rohan >"K. K. Ramakrishnan" wrote: > > > > I also appreciate the need to not have special casing for methods - > > but is this extra messaging coming about because we chose to > > have the PRACK as a "method"? On the issue of backwards compatibility, > > couldn't we say that proxies shouldn't be creating transaction state > > for things it doesn't understand? > >This proposal is itself not backwards compatible. Also, it doesn't seem >quite right - it would mean, for example, that proxies cannot fork on >requests they do not know. This seems like a big limitation. > >Anders From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 13:15:37 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15497 for ; Fri, 10 Mar 2000 13:15:35 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B12DF52DB; Fri, 10 Mar 2000 13:12:19 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 75A4452DF; Fri, 10 Mar 2000 13:12:17 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 54A2A52DB for ; Fri, 10 Mar 2000 13:11:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 10 13:10:51 EST 2000 Received: from smtprtp1.ntcom.nortel.net ([137.118.22.14]) by dusty; Fri Mar 10 13:08:15 EST 2000 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Fri, 10 Mar 2000 13:09:37 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 13:09:36 -0500 Message-ID: <63E0DAD7784FD21188310000F80824B3029C8D78@zmpkdx02.us.nortel.com> From: "Francois Audet" To: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Subject: RE: TRIP for gateway registrations Date: Fri, 10 Mar 2000 13:09:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8ABB.CAFA3198" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF8ABB.CAFA3198 Content-Type: text/plain; charset="iso-8859-1" I would point out that H.323 RAS messages are not normally used to register a range of phone numbers for gateways as it is quite impractical, especially for gateways handling a large number of phone numbers, and when keep-alive messages are used. While some implementations uses tricks such as registering "dialling prefixes" to map to telephone number, it is not the intent of prefixes which are supposed to be used for special services. Normally, a gateway registers an alias with its gatekeeper and the binding between the alias and the range of phone numbers handled by the gateway is "manually" configured in the gatekeeper, as described in the draft. I would think that TRIP could automate this process. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, March 09, 2000 11:33 PM > To: sip@lists.research.bell-labs.com; > iptel@lists.research.bell-labs.com > Subject: TRIP for gateway registrations > > > Folks, > > Every once in a while, the question comes up of why SIP > REGISTER is not > the right vehicle for allowing gateways to register phone > prefixes with > a proxy. I believe TRIP is far better for this purpose. As it > turns out, > a small subset of TRIP is needed to solve this problem, and yet its > still interoperable with full blown TRIP. Hussein Salama and I have > written an I-D that discusses this. Until it appears in the archives, > you can pick up a copy at: > > http://www.cs.columbia.edu/~jdrosen/papers/draft-rs-trip-gw-00.txt > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > ------_=_NextPart_001_01BF8ABB.CAFA3198 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: TRIP for gateway registrations

I would point out that H.323 RAS messages are not = normally
used to register a range of phone numbers for = gateways as it
is quite impractical, especially for gateways = handling a large
number of phone numbers, and when keep-alive = messages are used.

While some implementations uses tricks such as = registering
"dialling prefixes" to map to telephone = number, it is not the
intent of prefixes which are supposed to be used for = special services.

Normally, a gateway registers an alias with its = gatekeeper and the binding between the alias and the range of phone = numbers handled by the

gateway is "manually" configured in the = gatekeeper, as described
in the draft. I would think that TRIP could automate = this process.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, March 09, 2000 11:33 PM
> To: sip@lists.research.bell-labs.com;
> iptel@lists.research.bell-labs.com
> Subject: TRIP for gateway registrations
>
>
> Folks,
>
> Every once in a while, the question comes up of = why SIP
> REGISTER is not
> the right vehicle for allowing gateways to = register phone
> prefixes with
> a proxy. I believe TRIP is far better for this = purpose. As it
> turns out,
> a small subset of TRIP is needed to solve this = problem, and yet its
> still interoperable with full blown TRIP. = Hussein Salama and I have
> written an I-D that discusses this. Until it = appears in the archives,
> you can pick up a copy at:
>
> http://www.cs.columbia.edu/~jdrosen/papers/draft-rs-tr= ip-gw-00.txt
>
> Thanks,
> Jonathan R.
> --
> Jonathan D. = Rosenberg          &nb= sp;            = 200 Executive Drive
> Chief = Scientist          &nb= sp;           &nb= sp;      Suite 120
> = dynamicsoft          &= nbsp;           &= nbsp;          West = Orange, NJ 07052
> = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (732) 741-7244
> http://www.dynamicsoft.com
>
>

------_=_NextPart_001_01BF8ABB.CAFA3198-- From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 13:38:22 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23927 for ; Fri, 10 Mar 2000 13:38:21 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 384F452DE; Fri, 10 Mar 2000 13:35:44 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AAA6C52DF; Fri, 10 Mar 2000 13:35:43 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id EF23652DE for ; Fri, 10 Mar 2000 13:35:27 -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 NAA09534; Fri, 10 Mar 2000 13:35:23 -0500 (EST) Message-ID: <38C9406B.DD547641@cs.columbia.edu> Date: Fri, 10 Mar 2000 13:35:23 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Cc: Robert.Sparks@wcom.com Subject: Comments on transfer draft (sparks-sip-cc-transfer-00) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit A few low-level comments: - I'm not sure "TRANSFER" is the right verb here, since transfer implies moving something from one place to another. All TRANSFER does is effectively ask the recipient to send another INVITE. It would be nice if the same action could be used (say) for mesh conferences. While I agree that using methods is better than adding headers, we don't want one method per feature, if we can help it. (I.e., we should abstract what's happening at the signaling layer and then decide what operations are needed for that rather than just map feature to request name.) Maybe PLEASE-INVITE or something along these lines. That way, if we need a 'remote BYE', we can add 'PLEASE-BYE'. - Using TRANSFER instead of INVITE with Also does have one major disadvantage, since the originator of the request will retransmit with T2 (4 seconds). - According to the rules for feature names, IETF-based extensions are single words, to avoid any possible confusion with proprietary extensions having inverted domain names. Thus, it should probably just be Requires: transfer rather than cc.transfer. (On the other hand, it's not clear this is needed at all - we don't need Require for new methods, since they already have a mechanism to say "sorry, je ne comprend pas"). - Telepathy transfer: "UA receiving a well-formed TRANSFER request SHOULD request approval from the user to proceed. In the absence of that request, or upon ^^^^^^^^ --> If there's no request, the UAS spontaneously emits an INVITE? receiving approval from the user, the UA MUST submit an INVITE to the resource identified by the Transfer-To: header using the Call-ID from the TRANSFER request." Should probably be UAS, to make things clearer. From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 15:21:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01521 for ; Fri, 10 Mar 2000 15:21:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id ED42052DF; Fri, 10 Mar 2000 15:19:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 64CBA52E2; Fri, 10 Mar 2000 15:19:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B7EA252DF for ; Fri, 10 Mar 2000 15:19:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 10 15:17:48 EST 2000 Received: from mw.3com.com ([149.112.20.3]) by dusty; Fri Mar 10 15:15:08 EST 2000 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id OAA06731; Fri, 10 Mar 2000 14:17:31 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8625689E.006F9A6E ; Fri, 10 Mar 2000 14:19:00 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Anoop Tripathi" To: sip@lists.research.bell-labs.com Message-ID: <8625689E.006F99D7.00@mwgate02.mw.3com.com> Date: Fri, 10 Mar 2000 14:19:27 -0600 Subject: Fault tolerance scheme for SIP Proxy servers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, Is there a draft or a generally accepted fault tolerance scheme for SIP Proxy Servers? Essentially if a SIP Proxy server fails how does a standby server become the active without affecting the service ? Thanks, Anoop Tripathi 3COM From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 15:33:22 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05289 for ; Fri, 10 Mar 2000 15:33:22 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2BE8252E2; Fri, 10 Mar 2000 15:29:38 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A332F52E4; Fri, 10 Mar 2000 15:29:37 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A9FD552E2 for ; Fri, 10 Mar 2000 15:29:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 10 15:28:35 EST 2000 Received: from dgesmtp01.wcom.com ([199.249.16.16]) by dusty; Fri Mar 10 15:25:56 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FR800JB63JI27@firewall.mcit.com>; Fri, 10 Mar 2000 20:28:31 +0000 (GMT) Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id UAA04203; Fri, 10 Mar 2000 20:28:36 +0000 (GMT) Received: from C25776A ([166.44.56.147]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000310202828.DVBA1570@C25776A>; Fri, 10 Mar 2000 20:28:28 +0000 Date: Fri, 10 Mar 2000 14:28:24 -0600 From: Henry Sinnreich Subject: Interdomain SIP-QoS-OSP In-reply-to: <38C8A521.DBDCCC08@dynamicsoft.com> To: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Reply-To: henry.sinnreich@wcom.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Until it appears in the archive, there is a new draft version available at: http://www.softarmor.com/sipwg/drafts/draft-sinnreich-sip-qos-os p-01.txt Title: Interdomain IP Communications with QoS, Authorization and Usage Reporting Authors: H. Sinnreich, S. Donovan, D. Rawlins, S. Thomas Abstract Commercial grade IP telephony requires linkage between call setup, end-to-end QoS setup, interdomain authorization and accounting. This draft considers the network model for inter-domain QoS for access and transit networks, the service models and policy implementation options. Also, interdomain authorization and accounting may require the trust services of a clearinghouse, to which the local policy server may outsource authorization for support for inter-domain accounting. The draft defines two options for QoS support for telephony: PSTN- style "QoS Assured" or Internet-style "QoS Enabled" service. Implementing the local policy or QoS deployment can also have two options: The more usual policy "Pull Model" and the policy "Push Model" that may be advantageous for large IP telephony gateway deployments. The draft illustrates the various combinations of QoS service and policy implementation for interdomain QoS with authorization and accounting. Thanks, Henry Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Fri Mar 10 18:17:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03743 for ; Fri, 10 Mar 2000 18:17:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A4A6852B6; Fri, 10 Mar 2000 18:15:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 26E9D52E6; Fri, 10 Mar 2000 18:15:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 290D952B6 for ; Fri, 10 Mar 2000 18:15:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 10 18:14:32 EST 2000 To: sip@lists.research.bell-labs.com Received: from mail-blue.research.att.com ([135.207.30.102]) by dusty; Fri Mar 10 18:11:52 EST 2000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 6A3FD4CE3C for ; Fri, 10 Mar 2000 18:14:30 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id SAA17685 for ; Fri, 10 Mar 2000 18:14:29 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id SAA89483 for sip@lists.research.bell-labs.com; Fri, 10 Mar 2000 18:12:34 -0500 (EST) Date: Fri, 10 Mar 2000 18:12:34 -0500 (EST) Message-Id: <200003102312.SAA89483@fish-ha.research.att.com> Subject: new internet drafts posted Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk I've just posted an Internet Draft on the compromise position reached regarding the DCS group's two-stage invite proposal. It's entitled "Integration of Resource Management and SIP for IP Telephony", and is filed as draft-manyfolks-sip-resource-00. Until it appears in the archives, it may be obtained via anonymous ftp ftp://ftp.research.att.com/dist/wtm/draft-manyfolks-sip-resource-00.txt This draft is a combination of two previous drafts, draft-ietf-mmusic-sdp-qos-00, and draft-dcsgroup-sip-resource-00, and discusses how network QoS and security establishment can be made a precondition to sessions initiated by SIP, and how the resulting call setup mechanism achieves many goals, including those of the PacketCable DCS project. We anticipate no problems in reissuing this draft shortly after Adelaide with "full conformance with Section 10 of RFC2026." Also just posted are updates to 5 of the DCS group's Internet Drafts, draft-dcsgroup-sip-arch-01 draft-dcsgroup-sip-call-auth-01 draft-dcsgroup-sip-state-01 draft-dcsgroup-sip-privacy-01 draft-dcsgroup-sip-proxy-proxy-01 These drafts reflect the discussion at the November working group meeting, and further work since. Until they appear in the archives, they may be obtained via anonymous ftp ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sip-arch-01.txt ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sip-call-auth-01.txt ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sip-state-01.txt ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sip-privacy-01.txt ftp://ftp.research.att.com/dist/wtm/draft-dcsgroup-sip-proxy-proxy-01.txt Bill Marshall wtm@research.att.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 02:10:14 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15725 for ; Mon, 13 Mar 2000 02:10:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id ACAEE52C4; Mon, 13 Mar 2000 02:07:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 17B2052C8; Mon, 13 Mar 2000 02:07:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DEA2752C4 for ; Mon, 13 Mar 2000 02:07:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 02:05:16 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 02:04:45 EST 2000 Received: from dynamicsoft.com (1Cust106.tnt1.freehold.nj.da.uu.net [63.17.113.106]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA04484; Mon, 13 Mar 2000 02:05:08 -0500 (EST) Message-ID: <38CC9498.5F98852B@dynamicsoft.com> Date: Mon, 13 Mar 2000 02:11:20 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'sip@lists.research.bell-labs.com'" Subject: Re: Tag Values. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Fairlie-Cuninghame, Robert" wrote: > > I have a couple of questions regarding the tag value added to the {To} > header. > > The SIP RFC says that the tag value should be a UUID and (from a previous > post) that the UUID should/may be constructed using the standard format. The > RFC also says that "The "tag" value MUST be globally unique and > cryptographically random with at least 32 bits of randomness." > > So I take it that the tag can either be a UUID or 32bit random number ? They are not mutually exclusive. I believe that the timestamp in the UUID is sufficiently fine grained that a UUID has 32 bits of randomness. > > It has puzzled me why many traces have "tag=xxxxxxx" where xxxxxx is a > decimal number usually much less than 2^31. Why decimal and so small ? > [Whether the field is hex or decimal or UUID shouldn't matter since a > case-insensitive string comparison of the field is used, correct?] 32 bit number is not the same thing at all as 32 bits of randomness. 32 bits of randomness means that if you look at the tags as a random process, the entropy of the probability mass function is 32 bits. A simplistic way to view this is that the tags are random numbers between 1 and 2**32, with the probability of picking any particular one being 1 in 2**32. Thus, 1 is a perfectly valid tag and just as likely to show up as 2**32 -1. > > What is the current best practice for adding a tag when there is only one > Via line present? I think the spec uses an implicit MAY for this case but > has this been upgraded/clarified to a SHOULD or MUST ? That is, a UAS > SHOULD/MUST add a tag to final responses if there is one Via header (and of > course MUST if there are multiple Via's). I think rfc2543bis will make tag addition a MUST. Having to special case this is a big pain, as it turns out. We had it as a MAY in the first place, since we wanted to keep the direct client to client case simple. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 02:17:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18789 for ; Mon, 13 Mar 2000 02:17:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4751152D5; Mon, 13 Mar 2000 02:15:27 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7B60152C8; Mon, 13 Mar 2000 02:15:26 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 39A4E52D6 for ; Mon, 13 Mar 2000 02:15:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 02:14:39 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 02:14:09 EST 2000 Received: from dynamicsoft.com (1Cust106.tnt1.freehold.nj.da.uu.net [63.17.113.106]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA04488; Mon, 13 Mar 2000 02:14:36 -0500 (EST) Message-ID: <38CC96D0.EC75A8C2@dynamicsoft.com> Date: Mon, 13 Mar 2000 02:20:48 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: sip@lists.research.bell-labs.com Subject: Re: SIP for PSTN services References: <6525689C.0037596A.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit archow@hss.hns.com wrote: > > Hi, > We need to use SIP to connect to PSTN side Fax, click to dial etc. > I read through the PINT draft which is supposeldy catering to this type of > service. > > However, I wanted to know which approach to select. Is PINT the standard > way for PSTN service interaction ? > It seems whatever PINT states can be done with regular SIP - or is that > incorrect PINT provides three specific functions - click-to-dial, click-to-fax, and click-for-content. It is not a general purpose protocol for PSTN service interaction. The scope of PSTN service interaction is sufficiently large that I think there will be many ways. For example, look at the recent SPIRITS working group. It is possible to do these three services with vanilla SIP. There are significant differences in how the service is delivered, though, with pros and cons for both approaches. A colleague and I submitted a draft on Friday entitled "Third Party Call Control in SIP", which looks at a general purpose SIP approach for third party call control (its not an extension, just a usage). One of the services discussed is click to dial, and there is a brief comparison to pint. I'm sure there are other ways of providing this service beyond pint and whats in the draft. Until it appears in the archives, you can pick up a copy of the draft at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-3pcc-00.txt > > And is my understanding that PINT is nothing but SIP/SDP with some > extensions and is analogous to the various SIP extensions drafts > that are in existence today ? Yes. PINT extends SDP more than SIP, since it describes sessions that are purely on the telephone network. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 02:27:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22637 for ; Mon, 13 Mar 2000 02:27:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 377D352C8; Mon, 13 Mar 2000 02:25:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A73E752D6; Mon, 13 Mar 2000 02:25:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D67F352C8 for ; Mon, 13 Mar 2000 02:25:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 02:23:37 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 02:23:07 EST 2000 Received: from dynamicsoft.com (1Cust106.tnt1.freehold.nj.da.uu.net [63.17.113.106]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA04493; Mon, 13 Mar 2000 02:19:43 -0500 (EST) Message-ID: <38CC9803.91793822@dynamicsoft.com> Date: Mon, 13 Mar 2000 02:25:55 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft References: <38C53DEF.38649FF4@dynamicsoft.com> <38C65A11.C2551163@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > The draft talks about when it's OK to generate new reliable responses > for a transaction, but it doesn't seem to say anything about whether > final responses can be generated by a UAS which has outstanding > unacknowledged reliable responses. > > I believe the UAS must be allowed to generate a final response at any > time. Yes, agreed. > > The question is what happens with existing 'orphan' reliable responses > and corresponding PRACKS. They can either terminate normally, i.e. the > UAS continue retransmitting those reliable responses as it would have > done had a final response not been sent and likewise the UAC still > PRACKS them, or else maybe they could be terminated somehow - the UAS > stops retransmitting them, and the UAC never PRACKS anything for which > it has received a final response. Hmm. Good question. I tend to lean towards having those orphaned provisional responses still be PRACKED. Here's my reasoning: 1. These responses were sent reliably since they contain some important and useful information. It may be that this information is no longer useful once the final response is sent, but then again, it may be that it is still useful. So, if the user tries to send a provisional response reliably, lets always deliver it. Let the application decide whether its useful after a final response. 2. Lets keep transactions independent. We went through a similar thing with CANCEL, and the state machines were confusing until we decided to make CANCEL a mini-transaction that does nothing but ask the UAS to quickly answer the request. I think we will see confusion in the PRACK processing if its operation becomes dependent on events in other transactions. -Jonathan R. > > Anders > > -- > Anders Kristensen , > http://www-uk.hpl.hp.com/people/ak/ > Hewlett-Packard Labs, Bristol, UK -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 02:51:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02177 for ; Mon, 13 Mar 2000 02:51:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3569552AB; Mon, 13 Mar 2000 02:49:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A00B252DA; Mon, 13 Mar 2000 02:49:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9BCDF52AB for ; Mon, 13 Mar 2000 02:49:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 02:47:25 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 02:46:54 EST 2000 Received: from dynamicsoft.com (1Cust106.tnt1.freehold.nj.da.uu.net [63.17.113.106]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA04515; Mon, 13 Mar 2000 02:47:19 -0500 (EST) Message-ID: <38CC9E7B.884909F@dynamicsoft.com> Date: Mon, 13 Mar 2000 02:53:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Byerly Cc: sip@lists.research.bell-labs.com Subject: Re: Why do we need another header? Re: How to put a Kerberos ticket in SIP messages? References: <38C7CB74.120E3533@cisco.com> <38C7D2AD.D1A94FC3@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Before jumping into the syntax issues, I'd like to understand exactly whats going on here. Integration of Kerberos with SIP is a fairly big topic. There has been some discussion of this for establishing security associations between clients and local proxies as an alternative to IKE. You are proposing a different use yet, where it seems a redirect server is acting as a KDC, handing out tickets in SIP redirects. Lots of issues here, syntax is the least interesting one, IMHO. How is the client authenticating itself to the redirect/KDC in the first place? Does a client cache tickets and try to use them later when connecting to a server it was redirected to previously? What if the server thats redirected to, with a ticket, is yet another redirect server? I'm not saying I don't like this idea (in fact, I think its a very interesting one indeed), but I'd rather discuss higher level issues first. Actually, I'd love to see an I-D first to give a context for the discussion. -Jonathan R. Bryan Byerly wrote: > > So I expect a few people to come back and ask why not reuse an existing > header. > > I'm trying to achieve a flow where a SIP proxy hands back a Kerberos > ticket to a client. The client, in turn can use this ticket for > authorization to receive a service. (Yes, alternatively the client could > go get his own ticket (if he knew the IP address of the KDC and was an > authorized Kerberos client), and this follows along with moving complexity > out to the endpoints. However, I'm trying to initially simplify things > for dumber, less complex SIP clients. (and yes, I agree that SIP clients > could eventually go get their own tickets)). > > Let's go through the list of existing headers and why we can't use them: > > 401 WWW-Authenticate: header and Authorization: header > Using 401's WWW-Authenticate: header and the Authorization: header are > used for end-to-end authorization. So, using WWW-Authenticate is not > appropriate for passing back a Kerberos ticket. > > 407's Proxy-Authenticate: header and Proxy-Authorization: header > Using 407's Proxy-Authenticate: header and the Proxy-Authorization: header > are used to authorize a SIP client to transit through a SIP proxy. > Proxy-Authorization: is specified by a SIP client to provide credentials > such that he will be authorized by the SIP proxy. So, I don't think its > appropriate to overload Proxy-Authorization: to mean "here's an > authorization that the SIP proxy is passing to the SIP client". > > Response-Key: > This header is used by a client to specify a key which it requests the > called user agent should use to encrypt a response. So, its not > appropriate to use this header to pass a ticket. > > Thanks again for your help and suggestions! > > Bryan > > Bryan J. Byerly > byerly@cisco.com > > Bryan Byerly wrote: > > > Hi guys, > > > > I'm trying to understand how best to place a Kerberos (v5) ticket in > > SIP messages (i.e. either in SIP request or SIP response). > > (If someone already has such as draft, please forward me a copy.) > > > > I can think of two possible approaches: > > 1) Put it in a SIP header: > > 2) Put it in the SDP > > other ideas? > > > > 1) Thoughts on putting it in a header > > So, a Kerberos ticket is ASN.1 DER encoded. Is there any reason we > > couldn't just stick the binary representation of the ASN.1 DER encoded > > object in a header? > > Something like: > > ticket=fj7d543ghklc8654f7... > > (Yes, you're right, that's not a real ticket). > > > > So, I'm leaning towards a more generic header name like: > > Service-Authorization=[service name], [authorization-type], > > encoding=[encoding-type], ticket={octet string} > > authorization-type=kerberos5 > > encoding=octet-string > > > > b) Thoughts on putting it in the SDP > > > > Since a Kerberos ticket is ASN.1 DER encoded, it occurs to me that we'd > > need a email-safe version of the Kerberos ticket if we were to place it > > in the SDP. > > > > Can anyone point me to an existing draft/rfc which converts a Kerberos > > key to an email-safe version. I guess a draft on converting an > > arbitrary octet-string to an email-safe version would be fine too. > > > > P.S. > > For fun, who has a suggestion for which SDP abbreviation should be used > > for a Kerberos ticket? (It appears all the obvious ones are taken). > > taken: a, b, c, e, i, k, m, o, p, r, s, t, u, v, z > > remaining: f, g, h, j, l, n, q, w, x, y (Please correct me if some > > of these is already taken). > > > > Thanks for your help! > > > > Bryan > > > > Bryan J. Byerly > > byerly@cisco.com -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 02:55:31 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03552 for ; Mon, 13 Mar 2000 02:55:30 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9399F52DA; Mon, 13 Mar 2000 02:51:55 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CDC7E52DB; Mon, 13 Mar 2000 02:51:53 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id AB3C552DA for ; Mon, 13 Mar 2000 02:51:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 13 02:50:29 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 02:49:59 EST 2000 Received: from dynamicsoft.com (1Cust106.tnt1.freehold.nj.da.uu.net [63.17.113.106]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA04523; Mon, 13 Mar 2000 02:50:18 -0500 (EST) Message-ID: <38CC9F2E.76391F95@dynamicsoft.com> Date: Mon, 13 Mar 2000 02:56:30 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alan Johnston Cc: Rohan Mahy , sip@lists.research.bell-labs.com Subject: Re: I-D ACTION:draft-ietf-sip-call-flows-00.txt References: <200003091921.AAY16290@imop.cisco.com> <38C80B78.50A81E94@wcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Alan Johnston wrote: > > Rohan, > > You are correct - the Session:Media header is missing from all 183 responses in > the document. That will be fixed - thanks for pointing this out. > > I think the sequence of PRACKs and 200 OKs in scenario 4.1.2 (page 84) is > correct. PRACK is an end-to-end not hop-by-hop method (see Section 3 of > draft-ietf-sip-100rel), so the 200 OK response to it is generated by GW 1 and > forwarded by Proxy 1. This is why there is no requirement that proxies support > the reliable response feature, but both User Agents must support it. Correct. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 03:27:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16235 for ; Mon, 13 Mar 2000 03:27:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9DDEF52DB; Mon, 13 Mar 2000 03:25:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 10FC152B6; Mon, 13 Mar 2000 03:25:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id F33C552DB for ; Mon, 13 Mar 2000 03:25:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 13 03:23:08 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 03:22:38 EST 2000 Received: from dynamicsoft.com (1Cust106.tnt1.freehold.nj.da.uu.net [63.17.113.106]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA04545; Mon, 13 Mar 2000 03:23:04 -0500 (EST) Message-ID: <38CCA6DC.68BD6794@dynamicsoft.com> Date: Mon, 13 Mar 2000 03:29:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anoop Tripathi Cc: sip@lists.research.bell-labs.com Subject: Re: Fault tolerance scheme for SIP Proxy servers References: <8625689E.006F99D7.00@mwgate02.mw.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anoop Tripathi wrote: > > Hi, > > Is there a draft or a generally accepted fault tolerance scheme for SIP Proxy > Servers? There is no draft. I'm not even sure there should be (at least not standards track). How a server handles fault tolerance is an implementation issue. THere are numerous capabilities of SIP you can use to build robust systems. We have discussed several on the list, including multicast, statelessness, usage of domain names instead of IP addresses, and so on. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 08:04:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23490 for ; Mon, 13 Mar 2000 08:04:07 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A5DF552D6; Mon, 13 Mar 2000 08:01:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0BA5852DC; Mon, 13 Mar 2000 08:01:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 38D3152D6 for ; Mon, 13 Mar 2000 08:01:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 07:59:44 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Mon Mar 13 07:59:14 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id 23D031201; Mon, 13 Mar 2000 04:59:42 -0800 (PST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA21699; Mon, 13 Mar 2000 12:59:40 GMT Message-ID: <38CCE65A.855884C5@hplb.hpl.hp.com> Date: Mon, 13 Mar 2000 13:00:10 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft References: <38C53DEF.38649FF4@dynamicsoft.com> <38C65A11.C2551163@hplb.hpl.hp.com> <38CC9803.91793822@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Anders Kristensen wrote: > > > > The draft talks about when it's OK to generate new reliable responses > > for a transaction, but it doesn't seem to say anything about whether > > final responses can be generated by a UAS which has outstanding > > unacknowledged reliable responses. > > > > I believe the UAS must be allowed to generate a final response at any > > time. > > Yes, agreed. > > > > > The question is what happens with existing 'orphan' reliable responses > > and corresponding PRACKS. They can either terminate normally, i.e. the > > UAS continue retransmitting those reliable responses as it would have > > done had a final response not been sent and likewise the UAC still > > PRACKS them, or else maybe they could be terminated somehow - the UAS > > stops retransmitting them, and the UAC never PRACKS anything for which > > it has received a final response. > > Hmm. Good question. I tend to lean towards having those orphaned > provisional responses still be PRACKED. Here's my reasoning: > > 1. These responses were sent reliably since they contain some important > and useful information. It may be that this information is no longer > useful once the final response is sent, but then again, it may be that > it is still useful. So, if the user tries to send a provisional response > reliably, lets always deliver it. Let the application decide whether its > useful after a final response. > > 2. Lets keep transactions independent. We went through a similar thing > with CANCEL, and the state machines were confusing until we decided to > make CANCEL a mini-transaction that does nothing but ask the UAS to > quickly answer the request. I think we will see confusion in the PRACK > processing if its operation becomes dependent on events in other > transactions. It is certainly simpler to just always complete according to the original plan, so to speak. Interestingly, though, one might have thought it to be OK for the UAS to stop retransmitting reliable, un-PRACK'ed responses when it sends a final response. The theory here would be that this is so because either 1) the reliable response has been lost before reaching the UAC, and so there's no observable difference anywhere in the network from it never having been sent, or 2) the UAS did receive the reliable response so no retransmission are needed anyway. The only snag I can see is that some proxy somewhere may in fact be clever and act upon certain reliable responses, thus destroying assumption 1) above, so it would appear to be prudent for the UAS to retransmit as per the draft even in this case. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 08:23:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00616 for ; Mon, 13 Mar 2000 08:23:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CC13352DC; Mon, 13 Mar 2000 08:21:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3F8CD52DD; Mon, 13 Mar 2000 08:21:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8130452DC for ; Mon, 13 Mar 2000 08:21:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 08:20:26 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Mon Mar 13 08:19:56 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id 0D0A51420 for ; Mon, 13 Mar 2000 05:20:24 -0800 (PST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA23074 for ; Mon, 13 Mar 2000 13:20:22 GMT Message-ID: <38CCEB34.E5CE4B41@hplb.hpl.hp.com> Date: Mon, 13 Mar 2000 13:20:52 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP Subject: Session timer comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit A couple of comments on the session timer draft... The first is that I think it would be better if timer refreshing used a method other than INVITE, say TIMER-REFRESH. There are several drawbacks to reusing INVITE: o UAC must send a superfluous ACK for timer refresh responses o timer refresh INVITEs must carry a body which has no use whatsoever o overloading INVITE makes logic in UAS more complex o UAS may respond with non-200 which really doesn't make sense for timer refresh Secondly, on the open issues o Should we allow the UAC to insert a Require header in the request, indicating that the UAS must support the session timer? (I think no) This is allowed as per the definition of extensions and the Require header. Why would you go out of your way to disallow it in this case? o With this draft (and the previous versions), there was no way for the proxy to reject the call if the calling UA supported the session timer, but the called UA didn't. Is this a problem? If so, what can be done about it? (I think there is nothing we can do, and we should not worry about it) This seems to me to be a big problem. It means there are circumstances under which a call-statefull proxy *cannot* protect itself against DoS attacks. It *must* allow the session to proceed without timers. Fortunately there may be a simple solution: when a UAC sends an INVITE through a proxy indicating that it supports the 'timer' extension but without either "Require: timer" and "Session-Expires:" headers the proxy inserts a "Require: timer" before forwarding the INVITE: UAC -> Proxy INVITE Supported: timer Proxy -> UAS INVITE Supported: timer Require: timer Proxy <- UAS 420 Bad Extension Unsupported: timer UAC <- Proxy 420 Bad Extension Unsupported: timer This means that an INVITE which indicates support for session timers but without "Require: timer" can fail with "Unsupported: timer". This may seem a bit odd, but as we're defining an extension here we can just mandate that UACs must understand this response. A proxy which is willing to let the call go ahead without session timers may of course still choose not to insert the Require: timer header. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 09:11:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18014 for ; Mon, 13 Mar 2000 09:11:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B33F552B6; Mon, 13 Mar 2000 09:09:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 346BF52DE; Mon, 13 Mar 2000 09:09:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3A57B52B6 for ; Mon, 13 Mar 2000 09:09:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 09:08:48 EST 2000 Received: from awacs.vtel.com ([192.246.191.74]) by dusty; Mon Mar 13 09:08:17 EST 2000 Received: from ausexch01.vtel.com (ausexch01 [10.10.1.4]) by awacs.vtel.com (8.9.3/8.9.3) with ESMTP id IAA21512; Mon, 13 Mar 2000 08:08:45 -0600 (CST) Received: by ausexch01.vtel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Mar 2000 08:08:45 -0600 Message-ID: From: Joon Maeng To: sip@lists.research.bell-labs.com, ITU-SG16@mailbag.cps.intel.com, "'sip-h323@eGroups.com'" Subject: FYI - SIP-H.323 interworking discussion for IETF BOF Date: Mon, 13 Mar 2000 08:08:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi folks. To consolidate all the discussions related to SIP-H.323 interworking, SIP-H.323 interworking (sip323) BOF at IETF will use the list server at http://www.egroups.com/group/sip-h323/info.html. You can visit the site and register to use it. Regards, Joon From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 10:15:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12812 for ; Mon, 13 Mar 2000 10:15:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3E30A52AB; Mon, 13 Mar 2000 10:13:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B0D5452DA; Mon, 13 Mar 2000 10:13:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E20C452AB for ; Mon, 13 Mar 2000 10:13:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 10:12:07 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 10:11:36 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA04952; Mon, 13 Mar 2000 10:08:10 -0500 (EST) Message-ID: <38CD05D1.78A1BB87@dynamicsoft.com> Date: Mon, 13 Mar 2000 10:14:25 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft References: <38C53DEF.38649FF4@dynamicsoft.com> <38C65A11.C2551163@hplb.hpl.hp.com> <38CC9803.91793822@dynamicsoft.com> <38CCE65A.855884C5@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > > 2. Lets keep transactions independent. We went through a similar thing > > with CANCEL, and the state machines were confusing until we decided to > > make CANCEL a mini-transaction that does nothing but ask the UAS to > > quickly answer the request. I think we will see confusion in the PRACK > > processing if its operation becomes dependent on events in other > > transactions. > > It is certainly simpler to just always complete according to the > original plan, so to speak. Interestingly, though, one might have > thought it to be OK for the UAS to stop retransmitting reliable, > un-PRACK'ed responses when it sends a final response. The theory here > would be that this is so because either > 1) the reliable response has been lost before reaching the UAC, and so > there's no observable difference anywhere in the network from it never > having been sent, or > 2) the UAS did receive the reliable response so no retransmission are > needed anyway. > > The only snag I can see is that some proxy somewhere may in fact be > clever and act upon certain reliable responses, thus destroying > assumption 1) above, so it would appear to be prudent for the UAS to > retransmit as per the draft even in this case. Its not so much the proxy, as the UAC. If the UAS sent the response reliably, its probably because it contained some information that was important for the UAC to see. Otherwise, it wouldn't have sent it reliably in the first place. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 10:49:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26102 for ; Mon, 13 Mar 2000 10:49:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 84F7152C8; Mon, 13 Mar 2000 10:47:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F015E52D5; Mon, 13 Mar 2000 10:47:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BC90552C8 for ; Mon, 13 Mar 2000 10:47:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 10:45:31 EST 2000 Received: from atlrel1.hp.com ([156.153.255.210]) by dusty; Mon Mar 13 10:45:00 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel1.hp.com (Postfix) with ESMTP id 0377BE684; Mon, 13 Mar 2000 10:45:28 -0500 (EST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA01681; Mon, 13 Mar 2000 15:45:26 GMT Message-ID: <38CD0D33.413D4B3F@hplb.hpl.hp.com> Date: Mon, 13 Mar 2000 15:45:55 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft References: <38C53DEF.38649FF4@dynamicsoft.com> <38C65A11.C2551163@hplb.hpl.hp.com> <38CC9803.91793822@dynamicsoft.com> <38CCE65A.855884C5@hplb.hpl.hp.com> <38CD05D1.78A1BB87@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Anders Kristensen wrote: > > > > > 2. Lets keep transactions independent. We went through a similar thing > > > with CANCEL, and the state machines were confusing until we decided to > > > make CANCEL a mini-transaction that does nothing but ask the UAS to > > > quickly answer the request. I think we will see confusion in the PRACK > > > processing if its operation becomes dependent on events in other > > > transactions. > > > > It is certainly simpler to just always complete according to the > > original plan, so to speak. Interestingly, though, one might have > > thought it to be OK for the UAS to stop retransmitting reliable, > > un-PRACK'ed responses when it sends a final response. The theory here > > would be that this is so because either > > 1) the reliable response has been lost before reaching the UAC, and so > > there's no observable difference anywhere in the network from it never > > having been sent, or > > 2) the UAS did receive the reliable response so no retransmission are > > needed anyway. > > > > The only snag I can see is that some proxy somewhere may in fact be > > clever and act upon certain reliable responses, thus destroying > > assumption 1) above, so it would appear to be prudent for the UAS to > > retransmit as per the draft even in this case. > > Its not so much the proxy, as the UAC. If the UAS sent the response > reliably, its probably because it contained some information that was > important for the UAC to see. Otherwise, it wouldn't have sent it > reliably in the first place. The information carried in a reliable provisional response may or may not still be useful after a final response has been sent. Actually, I would expect most of the time it wouldn't be, but presumably the UAS would know and could make its choice accordingly. As I was saying I'm not advocating this, though. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 13:04:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19965 for ; Mon, 13 Mar 2000 13:04:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DDDA652D5; Mon, 13 Mar 2000 13:01:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5C07752DA; Mon, 13 Mar 2000 13:01:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 8007252D5 for ; Mon, 13 Mar 2000 13:01:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 13 12:59:15 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Mon Mar 13 12:58:44 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id MAA10059; Mon, 13 Mar 2000 12:59:10 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38CD5932.588FFA54@vovida.com> Date: Mon, 13 Mar 2000 13:10:10 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Subject: question in record-route Content-Type: multipart/alternative; boundary="------------D87EDA3D53573E24DA3549B5" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------D87EDA3D53573E24DA3549B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In record route, it is given that : if the response contained a contact header field, the user agent adds its content as the last route header. the question is; 1. after copying the content header field as the last record route item, should the content header field be deleted? ( it doesn't make sense otherwise) 2. Can the response containig Record route; contain more than one contat headers, and in that case, do all the contact headers be copied on to the route, and the contact headers deleted? thanks much! -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------D87EDA3D53573E24DA3549B5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit In record route, it is given that : if the response contained  a contact header field, the user agent adds its content as the last route header.

the question is;

1. after copying the content header field as the last record route item, should the content header field be deleted?  ( it doesn't make sense otherwise)

2. Can the response containig Record route;   contain more than one contat headers, and in that case, do all the contact headers be copied on to the route, and the contact headers deleted?

thanks much! 

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374
  --------------D87EDA3D53573E24DA3549B5-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 13:23:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28279 for ; Mon, 13 Mar 2000 13:23:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8C63F52DA; Mon, 13 Mar 2000 13:21:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 087AF52DB; Mon, 13 Mar 2000 13:21:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EC97752DA for ; Mon, 13 Mar 2000 13:21:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 13:19:53 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 13:19:22 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA05512; Mon, 13 Mar 2000 13:19:49 -0500 (EST) Message-ID: <38CD30D8.6261F884@dynamicsoft.com> Date: Mon, 13 Mar 2000 13:18:00 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Sunitha Kumar Cc: SIPbell-labs Subject: Re: question in record-route References: <38CD5932.588FFA54@vovida.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sunitha Kumar wrote: > In record route, it is given that : if the response contained a > contact header field, the user agent adds its content as the last > route header. > > the question is; > > 1. after copying the content header field as the last record route > item, should the content header field be deleted? ( it doesn't make > sense otherwise) The UAC should never copy UAS's Contact in its own future requests regardless of whether Record-Route is present or not. > 2. Can the response containig Record route; contain more than one > contat headers, ? No. Record-Route is only relevant for 200 class responses and those responses should never contain more than one Contact (with the exception of 2xx responses to REGISTER but it makes little sense to set up a Record-Route for those anyway). --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 17:26:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01221 for ; Mon, 13 Mar 2000 17:26:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6F02252D5; Mon, 13 Mar 2000 17:23:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D97E452D6; Mon, 13 Mar 2000 17:23:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A699952D5 for ; Mon, 13 Mar 2000 17:23:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 17:21:35 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Mon Mar 13 17:21:34 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id RAA11031; Mon, 13 Mar 2000 17:21:29 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38CD96AE.27B9E48F@vovida.com> Date: Mon, 13 Mar 2000 17:32:30 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: SIPbell-labs Subject: Re: question in record-route References: <38CD5932.588FFA54@vovida.com> <38CD30D8.6261F884@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------91686FFB5A0D0D1D467AF2FC" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------91686FFB5A0D0D1D467AF2FC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > Sunitha Kumar wrote: > > In record route, it is given that : if the response contained a > > contact header field, the user agent adds its content as the last > > route header. > > > > the question is; > > > > 1. after copying the content header field as the last record route > > item, should the content header field be deleted? ( it doesn't make > > sense otherwise) > > The UAC should never copy UAS's Contact in its own future requests > regardless of whether Record-Route is present or not. So, then, is there some inconsistency in the RFC, that needs to be addressed? Thanks! > > > > 2. Can the response containig Record route; contain more than one > > contat headers, ? > > No. Record-Route is only relevant for 200 class responses and those > responses should never contain more than one Contact (with the exception > of 2xx responses to REGISTER but it makes little sense to set up a > Record-Route for those anyway). > > --- > Igor Slepchin -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------91686FFB5A0D0D1D467AF2FC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Igor Slepchin wrote:
Sunitha Kumar wrote:
> In record route, it is given that : if the response contained  a
> contact header field, the user agent adds its content as the last
> route header.
>
> the question is;
>
> 1. after copying the content header field as the last record route
> item, should the content header field be deleted?  ( it doesn't make
> sense otherwise)

The UAC should never copy UAS's Contact in its own future requests
regardless of whether Record-Route is present or not.


So, then, is there some inconsistency in the RFC, that needs to be addressed?
 

Thanks!

 

> 2. Can the response containig Record route;   contain more than one
> contat headers, ?

No. Record-Route is only relevant for 200 class responses and those
responses should never contain more than one Contact (with the exception
of 2xx responses to REGISTER but it makes little sense to set up a
Record-Route for those anyway).

---
Igor Slepchin

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374
  --------------91686FFB5A0D0D1D467AF2FC-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 17:40:43 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07599 for ; Mon, 13 Mar 2000 17:40:42 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 847DB52DD; Mon, 13 Mar 2000 17:37:40 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 57E4152C4; Mon, 13 Mar 2000 17:37:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 31A7E52DB for ; Mon, 13 Mar 2000 17:37:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 17:36:47 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 17:36:46 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA06544; Mon, 13 Mar 2000 17:36:44 -0500 (EST) Message-ID: <38CD6EF0.DFC1AA82@dynamicsoft.com> Date: Mon, 13 Mar 2000 17:42:56 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sunitha Kumar Cc: Igor Slepchin , SIPbell-labs Subject: Re: question in record-route References: <38CD5932.588FFA54@vovida.com> <38CD30D8.6261F884@dynamicsoft.com> <38CD96AE.27B9E48F@vovida.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sunitha Kumar wrote: > > Igor Slepchin wrote: > > > Sunitha Kumar wrote: > > > In record route, it is given that : if the response contained a > > > contact header field, the user agent adds its content as the last > > > route header. > > > > > > the question is; > > > > > > 1. after copying the content header field as the last record route > > > > > item, should the content header field be deleted? ( it doesn't > > make > > > sense otherwise) > > > > The UAC should never copy UAS's Contact in its own future requests > > regardless of whether Record-Route is present or not. > > So, then, is there some inconsistency in the RFC, that needs to be > addressed? No; the RFC never says to copy the Contact field from the response to subsequent requests. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 17:43:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08538 for ; Mon, 13 Mar 2000 17:43:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B487252DB; Mon, 13 Mar 2000 17:37:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A1EFF52DC; Mon, 13 Mar 2000 17:37:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6030452C4 for ; Mon, 13 Mar 2000 17:37:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 17:36:33 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 17:36:32 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA06536; Mon, 13 Mar 2000 17:36:23 -0500 (EST) Message-ID: <38CD6CE2.60D5C758@dynamicsoft.com> Date: Mon, 13 Mar 2000 17:34:10 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Sunitha Kumar Cc: SIPbell-labs Subject: Re: question in record-route References: <38CD5932.588FFA54@vovida.com> <38CD30D8.6261F884@dynamicsoft.com> <38CD96AE.27B9E48F@vovida.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > > The UAC should never copy UAS's Contact in its own future requests > > regardless of whether Record-Route is present or not. > > So, then, is there some inconsistency in the RFC, that needs to be > addressed? > I don't really see any. If a UAC receives a response with Record-Route and a Contact, it adds the value from the Contact as the last element in the Route header it constructs. The future requests from UAC will then be forwarded according to the Route. If a UAC receives a request with a Contact and no Record-Route, it will send future requests to the entity listed in the Contact. In neither case will it copy the Contact header of the response into its own requests. --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 20:10:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04845 for ; Mon, 13 Mar 2000 20:10:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B932052DC; Mon, 13 Mar 2000 20:07:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2CA1752DE; Mon, 13 Mar 2000 20:07:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8962A52DC for ; Mon, 13 Mar 2000 20:07:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 20:06:11 EST 2000 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Mon Mar 13 20:06:09 EST 2000 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA05333; Mon, 13 Mar 2000 17:06:07 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA03709; Mon, 13 Mar 2000 17:06:07 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14541.36991.578327.402768@thomasm-u1.cisco.com> Date: Mon, 13 Mar 2000 17:06:07 -0800 (PST) To: Jonathan Rosenberg Cc: Bryan Byerly , sip@lists.research.bell-labs.com Subject: Re: Why do we need another header? Re: How to put a Kerberos ticket in SIP messages? In-Reply-To: <38CC9E7B.884909F@dynamicsoft.com> References: <38C7CB74.120E3533@cisco.com> <38C7D2AD.D1A94FC3@cisco.com> <38CC9E7B.884909F@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! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan, There are, in fact, two things going on here. 1) There is a need to secure the base level signaling hop by hop. Using Kerberized IPSec with the principle name being the FQDN of the box (eg port1@mybox.telco.net) is probably the right answer for high fanout networks. This would handle the cases where there is a one to one relationship between the users of the box and the box itself. It also handles the base level requirement for autheticity and privacy of the SIP traffic. 2) When multiple users can simultaneously use the same box (eg, mike@mybox.telco.net), we ALSO need a means of verifying the credentials of the individual user in addition to the credentials of the box itself. There are many possible answers here, running from HTTP basic authentication to public key signatures, but if you already need a kerberos client for other reasons (see #1 above), it would almost certainly be a win to transport a kerberos ticket for the Proxy-Authenticate. The nice thing here is that we can use either public key cryptography (I think of this in terms of a smart card I'd put into a public SIP phone), or "normal" symmetric key Kerberos depending on the application. The main attraction of public key Kerberos is that it captures the result of the public key operation in the ticket which can later be verified using just symmetric key operations (which are orders of magnitude faster). This is equally important in both cases 1 and 2 for large scale deployment. A few inline comments: Jonathan Rosenberg writes: > How is the client > authenticating itself to the redirect/KDC in the first place? It can either be done using public keys and certificates (PKINIT) or the normal method of username/passwords. > Does a > client cache tickets and try to use them later when connecting to a > server it was redirected to previously? Yes. > What if the server thats > redirected to, with a ticket, is yet another redirect server? If you use ticket granting tickets, you just get and maintain a ticket for each server you need to create an SA with. You rightly point out above that the tickets form a cache; nothing bad happens if you have to throw one away (other than needing to go back to the KDC on a cache miss). Mike From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 20:25:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09972 for ; Mon, 13 Mar 2000 20:25:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9656052DE; Mon, 13 Mar 2000 20:23:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 19F8852DF; Mon, 13 Mar 2000 20:23:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 2506152DE for ; Mon, 13 Mar 2000 20:23:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 13 20:22:14 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Mon Mar 13 20:22:13 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id UAA01467; Mon, 13 Mar 2000 20:22:09 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38CDC107.FA978348@vovida.com> Date: Mon, 13 Mar 2000 20:33:11 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Subject: Query on matching requests to responses at the proxies Content-Type: multipart/alternative; boundary="------------475885F5DA5365E9AFAA9F99" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------475885F5DA5365E9AFAA9F99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit How do we match requests to responses at the proxies.( other than the branch in the Via); using preferably the fields in a CallLeg, ( so that the call can be uniquely identified). Ex: responses to 2 INVITES Is it legal for the proxy to tag the from field of every request that it forwards or proxies on, and remove the From tag, when the response to that comes back, before passing it downstream. Making sure, that each proxy on the way, adds itself to the record route. So, they are traversed on the way back. on other thoughts, what about incrementing the CSeq for every request that goes out, and decrementing the CSeq , when the response for that arrives, before passing it downstream. Any thoughts will help. Thanks much! -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------475885F5DA5365E9AFAA9F99 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit How do we match requests to responses at the proxies.( other than the branch in the Via);
using preferably the fields in a CallLeg, ( so that the call can be uniquely identified).

Ex: responses to 2 INVITES
Is it legal for the proxy to tag the from field of every request that it forwards or proxies on, and remove the From tag, when the response to that comes back, before passing it  downstream.  Making sure, that each proxy on the way, adds itself to the record route.  So, they are traversed on the way back.

on other thoughts, what about incrementing the CSeq for every request that goes out, and decrementing the CSeq , when the response for that arrives, before passing it downstream.

Any thoughts will help. Thanks much! 

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374
  --------------475885F5DA5365E9AFAA9F99-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 22:54:10 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29916 for ; Mon, 13 Mar 2000 22:54:09 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C1A6E52D6; Mon, 13 Mar 2000 22:51:31 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4314852E0; Mon, 13 Mar 2000 22:51:31 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3F36B52D6 for ; Mon, 13 Mar 2000 22:51:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 13 22:49:51 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Mon Mar 13 22:49:49 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id JAA16904; Tue, 14 Mar 2000 09:47:57 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568A2.00153882 ; Tue, 14 Mar 2000 09:21:47 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Sunitha Kumar Cc: SIPbell-labs Message-ID: <652568A2.001537B6.00@sampark.hss.hns.com> Date: Tue, 14 Mar 2000 09:21:42 +0530 Subject: Re: Query on matching requests to responses at the proxies Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=ZHiZZNmpDzLQ4At4PKNUPbhuKdyn44I1JDVuiGW8vb4TVfErq4TZJbhh" Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --0__=ZHiZZNmpDzLQ4At4PKNUPbhuKdyn44I1JDVuiGW8vb4TVfErq4TZJbhh Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, the issue of matching a request to response is done using the usual From, To, CallID and CSeq headers, and has been documented clearly in the draft . A proxy, should not insert tags into messages it forwards as tags are only used for end to end identification (I think the discussion of branch vs Tags was clearly explained in a previous thread by Igor and is now a part of the FAQ) So, if your proxy is forking, it will include a branch-id for each forked branch - that id, along with the from, to , callid and cseq will identify req. to responses at the proxy. I dont see how playing with CSeq acheives a solution to the problem . Regds Arjun Sunitha Kumar on 03/14/2000 10:03:11 AM To: SIPbell-labs cc: Subject: Query on matching requests to responses at the proxies How do we match requests to responses at the proxies.( other than the branch in the Via); using preferably the fields in a CallLeg, ( so that the call can be uniquely identified). Ex: responses to 2 INVITES Is it legal for the proxy to tag the from field of every request that it forwards or proxies on, and remove the From tag, when the response to that comes back, before passing it downstream. Making sure, that each proxy on the way, adds itself to the record route. So, they are traversed on the way back. on other thoughts, what about incrementing the CSeq for every request that goes out, and decrementing the CSeq , when the response for that arrives, before passing it downstream. Any thoughts will help. Thanks much! -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --0__=ZHiZZNmpDzLQ4At4PKNUPbhuKdyn44I1JDVuiGW8vb4TVfErq4TZJbhh Content-type: text/html; name="att-1.htm" Content-Disposition: attachment; filename="att-1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KSG93IGRvIHdlIG1hdGNoIHJlcXVlc3RzIHRvIHJlc3BvbnNlcyBhdCB0 aGUgcHJveGllcy4oIG90aGVyIHRoYW4gdGhlIGJyYW5jaA0KaW4gdGhlIFZpYSk7DQo8YnI+dXNp bmcgcHJlZmVyYWJseSB0aGUgZmllbGRzIGluIGEgQ2FsbExlZywgKCBzbyB0aGF0IHRoZSBjYWxs IGNhbiBiZQ0KdW5pcXVlbHkgaWRlbnRpZmllZCkuDQo8cD5FeDogcmVzcG9uc2VzIHRvIDIgSU5W SVRFUw0KPGJyPklzIGl0IGxlZ2FsIGZvciB0aGUgcHJveHkgdG8gdGFnIHRoZSBmcm9tIGZpZWxk IG9mIGV2ZXJ5IHJlcXVlc3QgdGhhdA0KaXQgZm9yd2FyZHMgb3IgcHJveGllcyBvbiwgYW5kIHJl bW92ZSB0aGUgRnJvbSB0YWcsIHdoZW4gdGhlIHJlc3BvbnNlIHRvDQp0aGF0IGNvbWVzIGJhY2ss IGJlZm9yZSBwYXNzaW5nIGl0Jm5ic3A7IGRvd25zdHJlYW0uJm5ic3A7IE1ha2luZyBzdXJlLA0K dGhhdCBlYWNoIHByb3h5IG9uIHRoZSB3YXksIGFkZHMgaXRzZWxmIHRvIHRoZSByZWNvcmQgcm91 dGUuJm5ic3A7IFNvLA0KdGhleSBhcmUgdHJhdmVyc2VkIG9uIHRoZSB3YXkgYmFjay4NCjxwPm9u IG90aGVyIHRob3VnaHRzLCB3aGF0IGFib3V0IGluY3JlbWVudGluZyB0aGUgQ1NlcSBmb3IgZXZl cnkgcmVxdWVzdA0KdGhhdCBnb2VzIG91dCwgYW5kIGRlY3JlbWVudGluZyB0aGUgQ1NlcSAsIHdo ZW4gdGhlIHJlc3BvbnNlIGZvciB0aGF0IGFycml2ZXMsDQpiZWZvcmUgcGFzc2luZyBpdCBkb3du c3RyZWFtLg0KPHA+QW55IHRob3VnaHRzIHdpbGwgaGVscC4gVGhhbmtzIG11Y2ghDQo8cHJlPi0t Jm5ic3A7DQpTdW5pdGhhIEt1bWFyDQpTb2Z0d2FyZSBFbmdpbmVlcg0KVm92aWRhIE5ldHdvcmtz DQooNDA4KSA5NTcgLSA2Mzc0PC9wcmU+DQombmJzcDs8L2h0bWw+DQoNCg== --0__=ZHiZZNmpDzLQ4At4PKNUPbhuKdyn44I1JDVuiGW8vb4TVfErq4TZJbhh-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Mar 13 23:31:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13004 for ; Mon, 13 Mar 2000 23:31:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A852152E0; Mon, 13 Mar 2000 23:29:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1374F52E2; Mon, 13 Mar 2000 23:29:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id BF4C552E0 for ; Mon, 13 Mar 2000 23:29:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 13 23:28:45 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Mar 13 23:28:44 EST 2000 Received: from dynamicsoft.com (1Cust120.tnt1.freehold.nj.da.uu.net [63.17.113.120]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA06994; Mon, 13 Mar 2000 23:28:41 -0500 (EST) Message-ID: <38CDC172.76669E43@dynamicsoft.com> Date: Mon, 13 Mar 2000 23:34:58 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sunitha Kumar Cc: SIPbell-labs Subject: Re: Query on matching requests to responses at the proxies References: <38CDC107.FA978348@vovida.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sunitha Kumar wrote: > > How do we match requests to responses at the proxies.( other than the > branch in the Via); > using preferably the fields in a CallLeg, ( so that the call can be > uniquely identified). > > Ex: responses to 2 INVITES > Is it legal for the proxy to tag the from field of every request that > it forwards or proxies on, and remove the From tag, when the response > to that comes back, before passing it downstream. Making sure, that > each proxy on the way, adds itself to the record route. So, they are > traversed on the way back. Why do this? You'll break authentication and it won't work if a tag was already there. > > on other thoughts, what about incrementing the CSeq for every request > that goes out, and decrementing the CSeq , when the response for that > arrives, before passing it downstream. I also highly recommend against this. If the client sends a request with that same CSeq, which does not pass through your proxy somehow, things will be mightily confused. Also this doesn't work with authentication. Why do you want to do this? The spec is quite clear on how responses are matched to requests. Why does incrementing the CSeq help in any way? -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 01:18:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23227 for ; Tue, 14 Mar 2000 01:18:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7B7EE52E2; Tue, 14 Mar 2000 01:15:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E067552E5; Tue, 14 Mar 2000 01:15:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 312C952E2 for ; Tue, 14 Mar 2000 01:15:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 14 01:13:58 EST 2000 Received: from uucp1.nwnexus.com ([206.63.63.110]) by dusty; Tue Mar 14 01:13:58 EST 2000 Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id WAA12978; Mon, 13 Mar 2000 22:13:55 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA07957; Mon, 13 Mar 00 21:03:04 -0800 Date: Mon, 13 Mar 2000 21:03:03 -0800 (GMT-0800) From: "Bernard D. Aboba" To: Michael Thomas Cc: Jonathan Rosenberg , Bryan Byerly , sip@lists.research.bell-labs.com Subject: Re: Why do we need another header? Re: How to put a Kerberos ticket in SIP messages? In-Reply-To: <14541.36991.578327.402768@thomasm-u1.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > it would almost certainly be a win to > transport a kerberos ticket for the > Proxy-Authenticate. The nice thing here is that > we can use either public key cryptography (I > think of this in terms of a smart card I'd put > into a public SIP phone), or "normal" symmetric > key Kerberos depending on the application. > > The main attraction of public key Kerberos is > that it captures the result of the public key > operation in the ticket which can later be > verified using just symmetric key operations > (which are orders of magnitude faster). This > is equally important in both cases 1 and 2 > for large scale deployment. > This is indeed a good idea because other methods of supporting smartcard auth require that the smartcard be used on *every* connection. This is not only onerous for the user, but creates huge load on the authentication server. With Kerberos, you pull out the smartcard once and can continue to reuse the ticket after that until it expires. Of course, don't forget to include an authenticator in each request for replay immunity! An added benefit of PKINIT is that it can be used for roaming between providers if necessary. I'd add that similar issues come up in "Presence" applications so that kerberization is an obvious win there as well. BTW, what is "Kerberized IPSEC?" Is this IKE MM w/GSS_API authentication? From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 02:37:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03890 for ; Tue, 14 Mar 2000 02:37:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E21A952DF; Tue, 14 Mar 2000 02:35:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5592652E6; Tue, 14 Mar 2000 02:35:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6712252DF for ; Tue, 14 Mar 2000 02:35:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 02:33:44 EST 2000 Received: from mail.huawei.com.cn ([202.96.135.132]) by dusty; Tue Mar 14 02:33:43 EST 2000 Received: from y13638 ([10.108.22.162]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA12131 for ; Tue, 14 Mar 2000 15:33:52 +0800 Message-ID: <008101bf8d87$6898a9c0$a2166c0a@y13638.huawei.com.cn> Reply-To: "yinshaohua" From: "yinshaohua" To: Subject: About "The SIP servlet API" Date: Tue, 14 Mar 2000 15:32:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi : Now I have a discussion with my fellow, would you give some suggestions ? We want to make a SIP Stack which can be used in many softwares. My fellow consider that the SIP Stack will be realized providing that it presents the API of the draft " The SIP Servlet API". But I have some questions about the API: A. When using in sip server,the servlet dispaly less role: decode the SIP message and the decoded header can be reached by server , store the trasaction (call-id, to etc), create message and may set some values according to the transaction,retransmissions. In section 5.3 of the draft, there writes " These headers (call-id, from,to,cseq) should not need to be manipulated directly by servlets ", I think A SIP stack SHOULD complete essential sip call management and process some parameters, sending only the useful infomation for service but not all parameters of message to other module. B. As a module of a software, the provided API is so many that it can be said the module is not encapsulated. So it not benefit to software maintenance. I think a SIP stack only gives a series of abstract API which can be used by other module to complete the service stipulated by the protocol C. Due to so many API, it is difficult to replant a servlet to other use, meanwhile, the servlet is diffcult to maintain because it have not a legible limit with other module. D. The SIP STACK should guarantee the SIP message sent by it accord with SIP protocol, but the servlet will not due to offering the API.So there may send unlawful message when the servlet use in other software. Please give some suggestions. Thanks! Shaohua Yin 2000/3/10 From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 03:07:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15183 for ; Tue, 14 Mar 2000 03:07:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4FA6252E5; Tue, 14 Mar 2000 03:05:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BB42252E7; Tue, 14 Mar 2000 03:05:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5B60052E5 for ; Tue, 14 Mar 2000 03:05:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 03:03:04 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Tue Mar 14 03:03:00 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id NAA12045; Tue, 14 Mar 2000 13:56:05 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652568A2.002BEC09 ; Tue, 14 Mar 2000 13:29:44 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "yinshaohua" Cc: sip@lists.research.bell-labs.com Message-ID: <652568A2.002BEB7C.00@sampark.hss.hns.com> Date: Tue, 14 Mar 2000 13:29:43 +0530 Subject: Re: About "The SIP servlet API" Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, The "SIP Servelet API" and "Building a SIP Stack" are two very different things. If you want to build a SIP Stack, which can be used in many softwares as you say, you are looking at a generic stack that can be used to build UAs, Proxies, Redirects etc. In which case, you should not be bulding a SIP Servelet API only - this document models itself to the usual Web Server- Sevelet interface and focusses prmarily on Java, and for a specific intention - deferring SIP controls to Java classes as 'SIP Servelets' Again, thats harldy building a stack to suit all applications. Of course, you could derive APIs from it if you so wish, but the bottom line is what you want to do (build a generic sip stack) and what the servelet API propses are two different things. If your friend wants a servelet interface, and you think the servelet API draft suits you, sure you could implement it, but again, it does not *replace* a generic SIP stack, it would add on to it. Why dont you look at http://www.cs.columbia.edu/~hgs/sip/implementations.html - there are companies that have implemented generic stacks, and some of their links (follow it from the implementations page) give you an idea of expected features from a generic SIP Stack Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "yinshaohua" on 03/14/2000 01:02:09 PM Please respond to "yinshaohua" To: sip@lists.research.bell-labs.com cc: Subject: About "The SIP servlet API" Hi : Now I have a discussion with my fellow, would you give some suggestions ? We want to make a SIP Stack which can be used in many softwares. My fellow consider that the SIP Stack will be realized providing that it presents the API of the draft " The SIP Servlet API". But I have some questions about the API: A. When using in sip server,the servlet dispaly less role: decode the SIP message and the decoded header can be reached by server , store the trasaction (call-id, to etc), create message and may set some values according to the transaction,retransmissions. In section 5.3 of the draft, there writes " These headers (call-id, from,to,cseq) should not need to be manipulated directly by servlets ", I think A SIP stack SHOULD complete essential sip call management and process some parameters, sending only the useful infomation for service but not all parameters of message to other module. B. As a module of a software, the provided API is so many that it can be said the module is not encapsulated. So it not benefit to software maintenance. I think a SIP stack only gives a series of abstract API which can be used by other module to complete the service stipulated by the protocol C. Due to so many API, it is difficult to replant a servlet to other use, meanwhile, the servlet is diffcult to maintain because it have not a legible limit with other module. D. The SIP STACK should guarantee the SIP message sent by it accord with SIP protocol, but the servlet will not due to offering the API.So there may send unlawful message when the servlet use in other software. Please give some suggestions. Thanks! Shaohua Yin 2000/3/10 From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 08:30:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09272 for ; Tue, 14 Mar 2000 08:30:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4EF5652E7; Tue, 14 Mar 2000 08:27:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E1ACE52E6; Tue, 14 Mar 2000 08:27:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E174652E6 for ; Tue, 14 Mar 2000 08:27:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 08:26:59 EST 2000 Received: from crash.netspeak.com ([208.143.140.6]) by dusty; Tue Mar 14 08:26:59 EST 2000 Received: by crash with Internet Mail Service (5.5.2448.0) id ; Tue, 14 Mar 2000 08:26:58 -0500 Message-ID: From: Linden deCarmo To: "'sip@lists.research.bell-labs.com'" Subject: SIP & RTSP interworking? Date: Tue, 14 Mar 2000 08:26:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk What would be the proper (or suggested) procedure to tie a SIP session to an RTSP session? What I'd like to do is setup a session with SIP (via an INVITE), then control streaming aspects via RTSP (i.e. play, pause, stop etc.). However, its not clear to me how I tie the RTSP session id to the previously established SIP session. Thanks. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 09:44:16 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08915 for ; Tue, 14 Mar 2000 09:44:15 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DFFD752E6; Tue, 14 Mar 2000 09:41:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 60E6E52E9; Tue, 14 Mar 2000 09:41:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id E994C52E6 for ; Tue, 14 Mar 2000 09:41:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 14 09:40:03 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Tue Mar 14 09:40:01 EST 2000 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id IAA13717; Tue, 14 Mar 2000 08:39:59 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id IAA12074; Tue, 14 Mar 2000 08:39:58 -0600 (CST) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA01373; Tue, 14 Mar 2000 08:39:58 -0600 (CST) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id IAA20455; Tue, 14 Mar 2000 08:39:56 -0600 (CST) Date: Tue, 14 Mar 2000 08:39:56 -0600 (CST) Message-Id: <200003141439.IAA20455@b04a45.exu.ericsson.se> To: skumar@vovida.com Subject: Re: Query on matching requests to responses at the proxies Cc: sip@lists.research.bell-labs.com X-Sun-Charset: US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > > Sunitha Kumar wrote: > > > > How do we match requests to responses at the proxies.( other than the > > branch in the Via); > > using preferably the fields in a CallLeg, ( so that the call can be > > uniquely identified). > > > > Ex: responses to 2 INVITES > > Is it legal for the proxy to tag the from field of every request that > > it forwards or proxies on, and remove the From tag, when the response > > to that comes back, before passing it downstream. Making sure, that > > each proxy on the way, adds itself to the record route. So, they are > > traversed on the way back. > As already mentioned, this is a bad idea from an authentication point of view. Don't underestimate the power of including a Via: branch. With some creativity it can solve many many problems with correlating responses at proxies :) On that topic, is there any reason why a proxy shouldn't add a branch even if it does NOT fork the request? -- Sean Olson From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 11:18:28 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16797 for ; Tue, 14 Mar 2000 11:18:23 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C095B52F3; Tue, 14 Mar 2000 11:15:39 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D696C52F0; Tue, 14 Mar 2000 11:15:37 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id EBF5052ED for ; Tue, 14 Mar 2000 11:15:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 14 11:14:10 EST 2000 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Tue Mar 14 11:14:09 EST 2000 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA22710; Tue, 14 Mar 2000 08:14:05 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA03952; Tue, 14 Mar 2000 08:14:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14542.25934.68726.507042@thomasm-u1.cisco.com> Date: Tue, 14 Mar 2000 08:14:06 -0800 (PST) To: "Bernard D. Aboba" Cc: Michael Thomas , Jonathan Rosenberg , Bryan Byerly , sip@lists.research.bell-labs.com Subject: Re: Why do we need another header? Re: How to put a Kerberos ticket in SIP messages? In-Reply-To: References: <14541.36991.578327.402768@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! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Bernard D. Aboba writes: > > The main attraction of public key Kerberos is > > that it captures the result of the public key > > operation in the ticket which can later be > > verified using just symmetric key operations > > (which are orders of magnitude faster). This > > is equally important in both cases 1 and 2 > > for large scale deployment. > > > > This is indeed a good idea because other methods > of supporting smartcard auth require that the > smartcard be used on *every* connection. This > is not only onerous for the user, but creates > huge load on the authentication server. With > Kerberos, you pull out the smartcard once and > can continue to reuse the ticket after that > until it expires. Of course, don't forget to > include an authenticator in each request for > replay immunity! I don't think you need to include an authenticator so long as the base level transport is replay protected. This would be the case if you're using IPsec. As far as I can tell, you only need to challenge the particular user once ala http. > BTW, what is "Kerberized IPSEC?" Is this IKE > MM w/GSS_API authentication? No. Kerberized IPSec is something that got created at packetcable and doesn't use IKE at all. A normal kerberos ap_req/ap_rep are done to a well known port with a SPI and the ciphersuite information appended. There are no public key operations needed to key the the SA on the server. Mike From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 13:32:11 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09641 for ; Tue, 14 Mar 2000 13:32:07 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DFBE152DF; Tue, 14 Mar 2000 13:29:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5C09452E7; Tue, 14 Mar 2000 13:29:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 979D752DF for ; Tue, 14 Mar 2000 13:29:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 13:27:30 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 14 13:27:29 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA08173; Tue, 14 Mar 2000 13:27:07 -0500 (EST) Message-ID: <38CE83E4.E63AD784@dynamicsoft.com> Date: Tue, 14 Mar 2000 13:24:36 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: skumar@vovida.com Cc: sip@lists.research.bell-labs.com Subject: Re: Query on matching requests to responses at the proxies References: <200003141439.IAA20455@b04a45.exu.ericsson.se> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sean Olson wrote: > > On that topic, is there any reason why a proxy shouldn't add a branch > even if it does NOT fork the request? > No reason, it's free to do that if it likes. Moreover, it probably should if it wants to avoid balking on "fake" (aka spiral) loops discussed earlier on the list). --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 13:48:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16285 for ; Tue, 14 Mar 2000 13:47:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4FC4852D4; Tue, 14 Mar 2000 13:45:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BCAA252E8; Tue, 14 Mar 2000 13:45:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C863252D4 for ; Tue, 14 Mar 2000 13:45:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 13:44:45 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Tue Mar 14 13:44:44 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA06156; Tue, 14 Mar 2000 13:44:43 -0500 (EST) Message-ID: <38CE889A.602C80BF@cisco.com> Date: Tue, 14 Mar 2000 13:44:42 -0500 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: "headers" in SIP-URL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit A look at the syntax of SIP-URL shows that headers can be defined in a SIP-URL itself. However, the spec also says they MUST NOT be present in From/To and Request-URI. Does it mean they can be present in Contact header (the addr-spec portion of Contact) ?? I don't see any good reason for headers being allowed inside a SIP-URL and I would be curious to know how many implementations actually introduce it in SIP-URL ( probably the Contact header) and rely on it. Thanks, -- Best regards, Shail From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 13:55:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19921 for ; Tue, 14 Mar 2000 13:55:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4A09752E8; Tue, 14 Mar 2000 13:53:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C1C5F52E9; Tue, 14 Mar 2000 13:53:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B9FC552E8 for ; Tue, 14 Mar 2000 13:53:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 13:52:12 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue Mar 14 13:52:11 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA11538; Tue, 14 Mar 2000 13:52:04 -0500 (EST) Message-ID: <38CE8A4F.D2248151@cs.columbia.edu> Date: Tue, 14 Mar 2000 13:51:59 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Subject: Re: "headers" in SIP-URL References: <38CE889A.602C80BF@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > A look at the syntax of SIP-URL shows that headers can be defined in a SIP-URL > itself. However, the spec also says they MUST NOT be present in From/To and > Request-URI. Does it mean they can be present in Contact header (the addr-spec > portion of Contact) ?? > I don't see any good reason for headers being allowed inside a SIP-URL and I > would be curious to know how many implementations actually introduce it in > SIP-URL ( probably the Contact header) and rely on it. In a redirect, you can play tricks such as adding new headers to the next, redirected call. (For example, the redirect server could provide the password for another call.) While I doubt that it is used right now, it seems like a feature worth having around. > > Thanks, > > -- > Best regards, > Shail -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 14:00:10 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21508 for ; Tue, 14 Mar 2000 14:00:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BDF0852EA; Tue, 14 Mar 2000 13:57:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2BF3A52E9; Tue, 14 Mar 2000 13:57:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DF63952EA for ; Tue, 14 Mar 2000 13:57:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 13:56:58 EST 2000 Received: from mw.3com.com ([149.112.20.3]) by dusty; Tue Mar 14 13:56:57 EST 2000 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id MAA03051; Tue, 14 Mar 2000 12:56:39 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 862568A2.00683337 ; Tue, 14 Mar 2000 12:58:08 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Ravandhu Hariram" To: sip@lists.research.bell-labs.com Message-ID: <862568A2.006832A3.00@mwgate02.mw.3com.com> Date: Tue, 14 Mar 2000 12:58:11 -0600 Subject: Update of 'Contact' address Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk After a call is fully connected between two user agents, if one user agent sends a new INVITE request with a different 'Contact' address, should the receiving user agent update its 'Route' header with this modified 'Contact' address? Thanks, - hariram From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 14:24:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00676 for ; Tue, 14 Mar 2000 14:23:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 222BB52E9; Tue, 14 Mar 2000 14:21:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 89A6F52EB; Tue, 14 Mar 2000 14:21:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8D27A52E9 for ; Tue, 14 Mar 2000 14:21:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 14:20:50 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Tue Mar 14 14:20:49 EST 2000 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id NAA20669; Tue, 14 Mar 2000 13:20:48 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id NAA05246; Tue, 14 Mar 2000 13:20:46 -0600 (CST) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA18821; Tue, 14 Mar 2000 13:20:45 -0600 (CST) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id NAA02334; Tue, 14 Mar 2000 13:20:44 -0600 (CST) Date: Tue, 14 Mar 2000 13:20:44 -0600 (CST) Message-Id: <200003141920.NAA02334@b04a45.exu.ericsson.se> To: shbhatna@cisco.com, schulzrinne@cs.columbia.edu Subject: Re: "headers" in SIP-URL Cc: sip@lists.research.bell-labs.com X-Sun-Charset: US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > Shail Bhatnagar wrote: > > > > A look at the syntax of SIP-URL shows that headers can be defined in a SIP-URL > > itself. However, the spec also says they MUST NOT be present in From/To and > > Request-URI. Does it mean they can be present in Contact header (the addr-spec > > portion of Contact) ?? > > I don't see any good reason for headers being allowed inside a SIP-URL and I > > would be curious to know how many implementations actually introduce it in > > SIP-URL ( probably the Contact header) and rely on it. > > In a redirect, you can play tricks such as adding new headers to the > next, redirected call. (For example, the redirect server could provide > the password for another call.) While I doubt that it is used right now, > it seems like a feature worth having around. > > > Shail > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs The nice thing about the SIP-URL syntax is that is can represent everything you need to know to establish a call to that person. This makes it a natural representation for address books, v-card, etc. This also makes the SIP-URL fit naturally within web pages for future enhanced browsers. I don't see a good reason to disallow the headers or any other attribute of the SIP-URL in any header of the SIP message. The Contact: header of a registration or re-direct should definitely allow it for the reasons given above. -- Sean Olson From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 14:28:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02391 for ; Tue, 14 Mar 2000 14:28:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id F078352EC; Tue, 14 Mar 2000 14:23:54 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BABA952EB; Tue, 14 Mar 2000 14:23:52 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8C71C52EC for ; Tue, 14 Mar 2000 14:23:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 14:21:58 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 14 14:21:56 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA08375; Tue, 14 Mar 2000 14:21:39 -0500 (EST) Message-ID: <38CE90AD.C4ECFA2B@dynamicsoft.com> Date: Tue, 14 Mar 2000 14:19:09 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Henning Schulzrinne Cc: Shail Bhatnagar , sip@lists.research.bell-labs.com Subject: Re: "headers" in SIP-URL References: <38CE889A.602C80BF@cisco.com> <38CE8A4F.D2248151@cs.columbia.edu> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I actually used this in Siphone: you could include something like mailto:islepchin@dynamicsoft.com?Subject="I'm OOO, use email" in a redirect response and then the UAC would pop up a mail composer with the Subject line filled in (just a little boasting:) Back to the point: headers may also be quite useful when embedding SIP URLs in web pages; the RFC actually has an example of such a URL. --- Igor Slepchin Henning Schulzrinne wrote: > > Shail Bhatnagar wrote: > > > > A look at the syntax of SIP-URL shows that headers can be defined in a SIP-URL > > itself. However, the spec also says they MUST NOT be present in From/To and > > Request-URI. Does it mean they can be present in Contact header (the addr-spec > > portion of Contact) ?? > > I don't see any good reason for headers being allowed inside a SIP-URL and I > > would be curious to know how many implementations actually introduce it in > > SIP-URL ( probably the Contact header) and rely on it. > > In a redirect, you can play tricks such as adding new headers to the > next, redirected call. (For example, the redirect server could provide > the password for another call.) While I doubt that it is used right now, > it seems like a feature worth having around. > > > > > Thanks, > > > > -- > > Best regards, > > Shail > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 14:33:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04466 for ; Tue, 14 Mar 2000 14:33:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 21BA752ED; Tue, 14 Mar 2000 14:31:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9100752EB; Tue, 14 Mar 2000 14:31:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4D7BA52EF for ; Tue, 14 Mar 2000 14:31:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 14:29:46 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Tue Mar 14 14:29:45 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA09231; Tue, 14 Mar 2000 14:29:13 -0500 (EST) Message-ID: <38CE9309.D9007E20@cisco.com> Date: Tue, 14 Mar 2000 14:29:13 -0500 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip@lists.research.bell-labs.com Subject: Re: "headers" in SIP-URL References: <38CE889A.602C80BF@cisco.com> <38CE8A4F.D2248151@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > In a redirect, you can play tricks such as adding new headers to the > next, redirected call. (For example, the redirect server could provide > the password for another call.) While I doubt that it is used right now, > it seems like a feature worth having around. Are these headers copied to the next request - as long as one of the following is not specified : Call-ID, From, To and CSeq, Via ?? Any security issues with this ?? Thanks, Shail From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 15:21:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23991 for ; Tue, 14 Mar 2000 15:21:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8182952EF; Tue, 14 Mar 2000 15:19:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B42D552F0; Tue, 14 Mar 2000 15:19:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D8E0752EF for ; Tue, 14 Mar 2000 15:19:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 15:18:37 EST 2000 Received: from mail-dns1-nj.dialogic.com ([146.152.228.10]) by dusty; Tue Mar 14 15:18:36 EST 2000 Received: from mail5.Dialogic.com (mail5.dialogic.com [146.152.3.40]) by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id UAA11326 for ; Tue, 14 Mar 2000 20:20:12 GMT From: Jeff.Mark@Dialogic.com Received: from 100grand ([146.152.131.156]) by mail4.dialogic.com (PMDF V5.2-31 #33110) with SMTP id <0FRF00003HSUJW@mail4.dialogic.com> for sip@lists.research.bell-labs.com; Tue, 14 Mar 2000 15:19:43 -0500 (EST) Date: Tue, 14 Mar 2000 12:18:36 -0800 Subject: I-D ACTION:draft-mark-sip-dmcs-00.txt To: sip@lists.research.bell-labs.com Cc: Kalon.Kelley@Dialogic.com Message-id: <3E006CE92E9AD3119F4E00105A0C3807B0F961@exchange1nj.dialogic.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Message-Flag: Follow up Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7BIT Hi all, Just wanted to let you know of a new draft. Below is the announcement in case you missed it. We know there is other work going on in the call control services area (draft-ietf-sip-cc-01, and new drafts draft-campbell-sip-cc-framework-00 and draft-sparks-sip-cc-transfer-00) and hope the ideas presented in our draft below are of interest to others. Comments are appreciated. Thanks! -Jeff -- Jeff Mark Software Engineer Intel Dialogic Division mailto:Jeff.Mark@Dialogic.com http://www.dialogic.com/ -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, March 10, 2000 3:28 AM Subject: I-D ACTION:draft-mark-sip-dmcs-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Distributed Multipoint Conferences using SIP Author(s) : J. Mark, K. Kelley Filename : draft-mark-sip-dmcs-00.txt Pages : 56 Date : 09-Mar-00 This document describes a set of extensions to SIP, which allows distributed multipoint conferencing techniques. Building on prior work [1], we refine implementation strategies and advance additional services. We present refinements on existing multipoint call and transfer signaling techniques and introduce new services of merge and split. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mark-sip-dmcs-00.txt From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 18:15:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00073 for ; Tue, 14 Mar 2000 18:15:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E6E8352DF; Tue, 14 Mar 2000 18:13:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6B19752EE; Tue, 14 Mar 2000 18:13:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AC46452DF for ; Tue, 14 Mar 2000 18:13:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 18:11:32 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Tue Mar 14 18:11:31 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id SAA20713; Tue, 14 Mar 2000 18:10:41 -0500 (EST) Message-ID: <38CEC6F1.42380C6F@cisco.com> Date: Tue, 14 Mar 2000 18:10:41 -0500 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Receiver-tagged Via Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Can a stateful proxy simply save the upstream addr (for request) and port number of topmost Via it receives and not worry about resolving the Via header in the response ?? Then there is no need to append the received parameter to the Via of the previous hop. I understand that the mechanism allows stateless proxy to route the response correctly. Comments ?? -- Best regards, Shail From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 18:41:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09845 for ; Tue, 14 Mar 2000 18:41:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2557352EB; Tue, 14 Mar 2000 18:39:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9FCC652F0; Tue, 14 Mar 2000 18:39:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9057F52EB for ; Tue, 14 Mar 2000 18:39:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 18:38:41 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 14 18:38:40 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA09410; Tue, 14 Mar 2000 18:38:34 -0500 (EST) Message-ID: <38CECD10.3FFF7B7D@dynamicsoft.com> Date: Tue, 14 Mar 2000 18:36:48 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Subject: Re: Receiver-tagged Via References: <38CEC6F1.42380C6F@cisco.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > Can a stateful proxy simply save the upstream addr (for request) and port > number of topmost Via it receives and not worry about resolving the Via header > in the response ?? Then there is no need to append the received parameter to > the Via of the previous hop. I think it's OK to use the saved information if you still remember the transaction state when response is received. However, you still need to be prepared to process Via headers for responses for which there is no such state info, e.g., because the corresponding transaction state was destroyed due to a timeout or even because the proxy was rebooted. The implication is that you certainly need to add the received tag if the source IP address does not match that in the topmost Via. Also, note that _only_ the source IP address should be used, _NOT_ the port; the port should be taken from the Via (or assumed to be 5060 if none is present). --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Tue Mar 14 18:45:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10930 for ; Tue, 14 Mar 2000 18:45:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3125252F0; Tue, 14 Mar 2000 18:41:51 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 48F0552F1; Tue, 14 Mar 2000 18:41:50 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 52FA852F0 for ; Tue, 14 Mar 2000 18:41:11 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 14 18:40:18 EST 2000 Received: from diablo.cisco.com ([171.68.224.210]) by dusty; Tue Mar 14 18:40:17 EST 2000 Received: from jmpolk-8k ([171.71.126.180] (may be forged)) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA05724 for ; Tue, 14 Mar 2000 15:40:15 -0800 (PST) Message-Id: <4.1.20000314172759.00c0c9f0@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 14 Mar 2000 17:39:01 -0600 To: sip@lists.research.bell-labs.com From: "James M. Polk" Subject: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17320561==_.ALT" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --=====================_17320561==_.ALT Content-Type: text/plain; charset="us-ascii" All Like so many others -- I'm letting you know of a new Draft (draft-polk-sip-mlpp-mapping-00.txt) that addresses 'Multi-Level Precedence and Preemption' in SIP environments. Specifically it provides the background of existing Voice Networks that have specific requirements for differentiating Classes of Voice traffic, not just Voice from all other types of traffic. This I-D also recommends the ability to mandate the Header-Field 'Priority:' during session set-up within a domain (analagous to how the existing MLPP networks function today), but with the obvious advantages of IP (vs. TDM). I know that should get some attention by itself. Your comments regarding this draft are greatly appreciated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-polk-sip-mlpp-mapping-00.txt Cheers! ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_17320561==_.ALT Content-Type: text/html; charset="us-ascii"
All

Like so many others -- I'm letting you know of a new Draft (draft-polk-sip-mlpp-mapping-00.txt) that addresses 'Multi-Level Precedence and Preemption' in SIP environments. Specifically it provides the background of existing Voice Networks that have specific requirements for differentiating Classes of Voice traffic, not just Voice from all other types of traffic. This I-D also recommends the ability to mandate the Header-Field 'Priority:' during session set-up within a domain (analagous to how the existing MLPP  networks function today), but with the obvious advantages of IP (vs. TDM). I know that should get some attention by itself.

Your comments regarding this draft are greatly appreciated.

A URL for this Internet-Draft is:

Cheers!
*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_17320561==_.ALT-- From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 02:32:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08305 for ; Wed, 15 Mar 2000 02:32:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A4B4252F1; Wed, 15 Mar 2000 02:29:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 25A7452F3; Wed, 15 Mar 2000 02:29:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CC20452F1 for ; Wed, 15 Mar 2000 02:29:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 02:28:06 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 15 02:28:05 EST 2000 Received: from dynamicsoft.com (1Cust12.tnt1.freehold.nj.da.uu.net [63.17.113.12]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA09822; Wed, 15 Mar 2000 02:25:37 -0500 (EST) Message-ID: <38CF11A4.F04178D4@dynamicsoft.com> Date: Tue, 14 Mar 2000 23:29:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: "Adam B. Roach" , sip@lists.research.bell-labs.com Subject: Re: Two New Drafts References: <6525689E.0030D6CF.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I think we are once again jumping the gun a bit. There are some much bigger issues to address with a generic sip subscription/notification mechanism: 1. what entities are generating the notifications? It can be a UA, or it could be a proxy or registrar. 2. What are the types of events we want to support subscriptions for? I know Adam has tried to keep that the subject of future extensions. Problem is, this issue has a strong impact on the addressing, event description and scaling capabilities. I don't think we can leave this to future extensions without having the "base" version have nothing but two methods. That doesn't really help much. I think we can define reasonably broad classes of events. Certainly we aren't interested in supporting events like "let me know when the coffee machine is done". 3. To whom does one address a subscription? If we address it to a user, what does that mean? Are we asking for a subscription to that users registration state? Also, before we get to far with architecture and design issues, there is the question about whether this concept, in general, is something the working group is interested in pursuing. -Jonathan R. archow@hss.hns.com wrote: > > Hi, > responses embedded and preceded by ARC> > > >The draft does not mention what happens when multiple SUBSCRIBE requests > >arrive from the same user. In REGISTER, > > they replace old ones if the SIP url is same and additive otherwise. > >However, in SUBSCRIBE, I think it would make sense to make it additive > >only, since the same SIP url can subscribe to multiple events using diff. > >subscription messages. Is this correct ? > > That sounds good, except possibly for the same "call leg". I think the > part that needs to be clarified is: if a user sends a SUBSCRIBE > which has the same Call-ID, From, and To as a previous request, > does it add events or override them? I'm leaning towards overrriding > events, since there is no easy way to remove events otherwise. Note well > that this wouldn't apply to other subscriptions with different Call-IDs, > which would (of course) remain additive. > > ARC> Somehow, I feel Call-ID and suscription should not be tied together. > This is primarily > ARC> because callid is generated by a terminal and a user has no control > over it. > ARC> However, a subscription is for a user, not a terminal. so if I > subscribe to a set of services > ARC> today, if I travel tomorrow, I want to walk into a Cyber Cafe, log in > using some applet based > ARC> sip client that will generate a different Call-ID from my old desktop > one an still be able to > ARC> access my old subscription list and add/del from it without having to > know the Call-Id - which > ARC> in many cases, I never get to see as a user. > ARC> but the moment the backend notifier works on Call-ID - then I would > never be able to 'Add' to > ARC> my list since Ill be using a different Call-ID in all probability, > neither will I be able to > ARC> somehow retrieve the old one, since match will never be true. > ARC> This is why I feel subscription should not be linked to a call - id. > > (Incidentally, I like your example. I have recently had > discussions with several different groups of people who > wanted to know how one would go about, for example, having > a light blink on your phone and/or have a distinctive dial > tone when a message is waiting). > > ARC> Well, we actually had exactly the above requirement once, and we did > it my adding > ARC> an Event like field with more or less the same semantics as we > discussed above. > > >Event = 1#(eventid ; duration) > >event = token // Does it need to be broken ? > >duration = deltaseconds | SIP-Date > > I don't really like this. Beyond the problems with using > commas for separators *and* having commas appear in > the duration (if the SIP-Date format is used), I'm trying to > keep it as congruent as possible with REGISTER, since the > semantics for that are already well defined -- and code is > already written to handle it. For the above situation, I'd > propose that you either: a) send all three REGISTER messages, > with different Call-IDs, in a single UDP packet, or b) send > a single REGISTER for all three events with an expires of 2 > hours. At the end of the 2 hours, re-SUBSCRIBE for just B > and C (expires in one hour), and one hour later, re-SUBSCRIBE > for just C. (A variation on this theme would be to subscribe > for 4 hours, override it in 2, and then again one hour later; > I prefer this method, since it eliminates the chances of missing > events -- although it counts on the addition vs. replacement > semantics I describe above). > > ARC> I assume where ever you mentioned REGISTER above , you meant SUBSCRIBE > ARC> Again, solution 1 is to me, a kind of loose workaround. And the other > solutions > ARC> force the client to maintain time differentiators actively since it > must physically > ARC> maniuplate subscriptions to implement the common requirement above. > Rather, The > ARC> Notifier is actually already implementing a timer list which can > notify users > ARC> based on differential time values maybe, so why force the client into > maintain the > ARC> differential list also ? To me it seems to be much cleaner for the > client to specify > ARC> it once, and forget about it, as the notifier server is there just to > remind him anyway > ARC> so why bog him down with keeping track of such requests ? > ARC> The only -ve point seems to be parsing for commas (which is a non > issue for good parsers) > ARC> - but if that really is a problem, maybe we could work at a simpler > expiry type ? > ARC> However, I dont feel parsing should be the reason to adopt the > alternate methods suggested > ARC> above. What do you/others feel abt it ? > > I must have been somewhat unclear. I am not proposing that one > use REGISTER itself to cancel a subscription; merely that one > use the same *mechanism*, with a SUBSCRIBE method. For > example, let's say that I want to cancel the subscription(s) > above. I could do so by sending: > > ARC> Sorry, I misinterpreted, then. Seems fine to me. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 02:35:35 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09756 for ; Wed, 15 Mar 2000 02:35:35 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 67C1952F3; Wed, 15 Mar 2000 02:31:55 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3464852F4; Wed, 15 Mar 2000 02:31:53 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 571DB52F3 for ; Wed, 15 Mar 2000 02:31:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 15 02:29:34 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 15 02:29:33 EST 2000 Received: from dynamicsoft.com (1Cust12.tnt1.freehold.nj.da.uu.net [63.17.113.12]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA09826; Wed, 15 Mar 2000 02:25:41 -0500 (EST) Message-ID: <38CF1450.ED323ED6@dynamicsoft.com> Date: Tue, 14 Mar 2000 23:40:48 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: Anders Kristensen , kkrama@research.att.com, sip@lists.research.bell-labs.com Subject: Re: Provisional Response Draft References: <200003091921.AAY16299@imop.cisco.com> <4.2.0.58.20000310091028.00cb23c0@lint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > > Hi, > > At 12:09 PM 3/9/00 , Jonathan Rosenberg wrote: > >All requests are responded to. period. > > I never debated this. The user agents will always have an opportunity to > respond. > > I agree with kkrama@research.att.com, that proxies shouldn't keep state for > methods they don't understand. They can simply forward messages for these > unknown methods on to the user agents or the next proxy. If you want to build your proxy that way, fine. But I think it is asking to much to mandate that unknown methods be forwarded statelessly. The spec as written does not mandate this. > So what I hear Jonathan saying is that because some proxies MIGHT keep > state for new methods, then we need 200 OK, so that we don't break them. > Correct? I am personally curious how many proxies would break. > > Also, I hear Jonathan saying that new methods should be processed in the > same way, and that this encourages simplicity. Aside from the comment > above, is there another motivation for this? Yes. It leads to a clean architectural implementation. It means I can build a base transaction mechanism that handles retransmissions and provisional responses and stuff without detailed message semantics, and then build semantic processing on top of this. It is this same motivation which has led me to conclude that transactions must be kept independent; so that, for example, if I send a BYE for an INVITE that hasn't been answered, the UAS should still answer the INVITE. The issue of allowing stateful proxies for unknown methods is a big one as well. It means that SIPs routing and searching capabilities can be reused for other services (i.e., other methods) with existing proxies. I think this is not to be dismissed so lightly. While there are clear advantages to keeping the 200 OK to PRACK, the only advantage I have heard to date for dropping it is message efficiency. In general, I firmly believe that generality and broad applicability are far more important design goals than message efficiency. I discuss this in more detail in the draft I recently submitted entitled "Guidelines for Authors of SIP Extensions". -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 03:17:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25656 for ; Wed, 15 Mar 2000 03:17:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 030FD52F2; Wed, 15 Mar 2000 03:15:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6D50252F5; Wed, 15 Mar 2000 03:15:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A18AD52F2 for ; Wed, 15 Mar 2000 03:15:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 03:14:47 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 15 03:14:46 EST 2000 Received: from dynamicsoft.com (1Cust12.tnt1.freehold.nj.da.uu.net [63.17.113.12]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA09882; Wed, 15 Mar 2000 03:14:43 -0500 (EST) Message-ID: <38CF47F2.DF71D8F9@dynamicsoft.com> Date: Wed, 15 Mar 2000 03:21:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff.Mark@Dialogic.com Cc: sip@lists.research.bell-labs.com, Kalon.Kelley@Dialogic.com Subject: Re: I-D ACTION:draft-mark-sip-dmcs-00.txt References: <3E006CE92E9AD3119F4E00105A0C3807B0F961@exchange1nj.dialogic.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Also, please note that an IPR statement has been made regarding this draft. It can be found at: http://www.ietf.org/ietf/IPR/DIALOGIC-SIP-DMCS -Jonathan R. Jeff.Mark@Dialogic.com wrote: > > Hi all, > > Just wanted to let you know of a new draft. Below is the announcement in > case you missed it. We know there is other work going on in the call > control services area (draft-ietf-sip-cc-01, and new drafts > draft-campbell-sip-cc-framework-00 and draft-sparks-sip-cc-transfer-00) > and hope the ideas presented in our draft below are of interest to others. > > Comments are appreciated. > > Thanks! > > -Jeff > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 03:27:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28622 for ; Wed, 15 Mar 2000 03:27:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 027C452F5; Wed, 15 Mar 2000 03:25:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6D12C52F6; Wed, 15 Mar 2000 03:25:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 72EA552F5 for ; Wed, 15 Mar 2000 03:25:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 03:23:39 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 15 03:23:39 EST 2000 Received: from dynamicsoft.com (1Cust12.tnt1.freehold.nj.da.uu.net [63.17.113.12]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA09887; Wed, 15 Mar 2000 03:23:32 -0500 (EST) Message-ID: <38CF4A03.3DDED452@dynamicsoft.com> Date: Wed, 15 Mar 2000 03:29:55 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: Henning Schulzrinne , sip@lists.research.bell-labs.com Subject: Re: "headers" in SIP-URL References: <38CE889A.602C80BF@cisco.com> <38CE8A4F.D2248151@cs.columbia.edu> <38CE9309.D9007E20@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > Henning Schulzrinne wrote: > > > > In a redirect, you can play tricks such as adding new headers to the > > next, redirected call. (For example, the redirect server could provide > > the password for another call.) While I doubt that it is used right now, > > it seems like a feature worth having around. It has tons of uses, actually. One example is debit card calling; a user calls a number, is authenticated to some system, and is then redirected (or transferred), with the Contact in the redirect containing either an Authorization header, or even a body with some kind of token (like an OSP token). I would definitely recommend that people implement this. > > Are these headers copied to the next request - as long as one of the following > is not specified : > Call-ID, From, To and CSeq, Via ?? Hmmm; this is a good question. I believe a client should generally copy all of them. I know of several cool services which require Call-ID, From, To and CSeq to be copied. The only possible exception is Via and Contact, since then the response (and subsequent requests) may not get back if this is not formulated correctly. However, I suppose that if a server redirects and puts a Via in the redirect URL, its just asking for trouble, and shouldn't complain if the service doesn't work. So, copy them all. > > Any security issues with this ?? There are certainly interesting attacks that can be launched by redirecting people to URLs with various headers placed in there. However, I think these are all solved by making sure to authenticate a redirect response. I think we might want to comment in the revised spec, in the section on Contact, about handling of headers in URLs. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 03:49:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05404 for ; Wed, 15 Mar 2000 03:49:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D294952F4; Wed, 15 Mar 2000 03:47:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5BBB052F8; Wed, 15 Mar 2000 03:47:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A82FE52F4 for ; Wed, 15 Mar 2000 03:47:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 15 03:46:15 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 15 03:46:14 EST 2000 Received: from dynamicsoft.com (1Cust12.tnt1.freehold.nj.da.uu.net [63.17.113.12]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA09923; Wed, 15 Mar 2000 03:46:11 -0500 (EST) Message-ID: <38CF4F52.D5A8E385@dynamicsoft.com> Date: Wed, 15 Mar 2000 03:52:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ravandhu Hariram Cc: sip@lists.research.bell-labs.com Subject: Re: Update of 'Contact' address References: <862568A2.006832A3.00@mwgate02.mw.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Ravandhu Hariram wrote: > > After a call is fully connected between two user agents, if one user agent sends > a new INVITE request with a different 'Contact' address, should the receiving > user agent update its 'Route' header with this modified 'Contact' address? I think so. There are a few applications of this, including mobility and a few call services. Note, however, that updating of the Route with new Record-Route headers is different. RFC2543 forbids (I think) insertion of Record-Route headers when a Route is already there. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 04:18:17 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14968 for ; Wed, 15 Mar 2000 04:18:16 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3C1E352F9; Wed, 15 Mar 2000 04:15:37 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AB0A552FA; Wed, 15 Mar 2000 04:15:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3BC0852F9 for ; Wed, 15 Mar 2000 04:15:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 04:13:57 EST 2000 Received: from fw9.telekom.de ([62.156.152.68]) by dusty; Wed Mar 15 04:13:56 EST 2000 Received: by fw9.telekom.de; (5.65v4.0/1.3/10May95) id AA17812; Wed, 15 Mar 2000 10:13:54 +0100 Received: from G8PXB.blf01.telekom.de by U8PW4.blf01.telekom.de with ESMTP; Wed, 15 Mar 2000 10:13:51 +0100 Received: from g8pbq.blf01.telekom.de by G8PXB.blf01.telekom.de with ESMTP; Wed, 15 Mar 2000 10:12:21 +0100 Received: by G8PBQ.blf01.telekom.de with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 10:12:19 +0100 Message-Id: <8FCDC1EF5ADCD211AC670800060D98A601522614@U8P15> From: "Liess, Laura" To: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Subject: uploading services from the user's home network to a sip server of the visited network within a 3G.IP environement Date: Wed, 15 Mar 2000 10:12:18 +0100 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, after doing a very good job by deciding to take SIP for call control for multimedia services within 3G.IP networks, the 3G.IP operators have a lot of open items concerning the architecture, one of them being which network controls the services for a roaming user: the home network, the visited network or shared control. The concrete question: how can I upload at the begin or during the call the roamimg user's services available in the home network into the SIP proxy of the visited network? As far as I know, the CPL and REGISTER helps me to upload services only from the UA to the proxy. Is anyone else working on similar issues? I know of the Telcordia mobility efforts, but the 3G.IP requirements and architecture seem to be somehow different. The 3G.IP operators would like to reuse their just implemented GPRS and the GPRS mobility. Thanks a lot Laura From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 07:32:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25140 for ; Wed, 15 Mar 2000 07:31:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C50DA52F8; Wed, 15 Mar 2000 07:29:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 425CB52FB; Wed, 15 Mar 2000 07:29:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A572852F8 for ; Wed, 15 Mar 2000 07:29:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 07:27:51 EST 2000 Received: from cmailg5.svr.pol.co.uk ([195.92.195.175]) by dusty; Wed Mar 15 07:27:50 EST 2000 Received: from modem-79.caranthir.dialup.pol.co.uk ([62.136.145.79] helo=theseventhson.freeserve.co.uk) by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12VCti-0004yH-00 for sip@lists.research.bell-labs.com; Wed, 15 Mar 2000 12:27:34 +0000 Message-ID: <38CF8150.77A36028@theseventhson.freeserve.co.uk> Date: Wed, 15 Mar 2000 12:25:52 +0000 From: Benny Prijono X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Different Via grammar in the web Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The Via grammar specified in the Columbia.edu's SIP page (http://www.cs.columbia.edu/sip/SIPgrammar.html#via) is different from the one in the draft. The difference is in the extension-params, i.e. the grammar in the web specifies that extension-params apply to the whole Via header, while the draft specifies that extension-params apply to each Via element. This is the one in the web page: Via = ( "Via" | "v") ":" 1#(sent-protocol sent-by *( ";" via-params ) [ comment ] ) *(";" extension-params) And this is the one in the draft: Via = ( "Via" | "v") ":" 1#(sent-protocol sent-by *( ";" via-params ) [ comment ] ) via-params = ... | via-extension Can anybody specify which one is correct? cheers, Bennylp From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 11:17:35 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28865 for ; Wed, 15 Mar 2000 11:17:34 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CCCBB52F6; Wed, 15 Mar 2000 11:13:46 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 26E8F52FD; Wed, 15 Mar 2000 11:13:45 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C6B5D52F6 for ; Wed, 15 Mar 2000 11:13:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 11:11:58 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Mar 15 11:11:57 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA10719; Wed, 15 Mar 2000 11:11:45 -0500 (EST) Message-ID: <38CFB7C3.9D64461E@dynamicsoft.com> Date: Wed, 15 Mar 2000 11:18:11 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Liess, Laura" Cc: sip@lists.research.bell-labs.com, iptel@lists.research.bell-labs.com Subject: Re: uploading services from the user's home network to a sip server of the visited network within a 3G.IP environement References: <8FCDC1EF5ADCD211AC670800060D98A601522614@U8P15> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Liess, Laura" wrote: > > Hi, > > after doing a very good job by deciding to take SIP for call control for multimedia services within 3G.IP >networks, the 3G.IP operators have a lot of open items concerning the architecture, one of them being which >network controls the services for a roaming user: the home network, the visited network or shared control. >The concrete question: how can I upload at the begin or during the call the roamimg user's services >available in the home network into the SIP proxy of the visited network? As far as I know, the CPL and >REGISTER helps me to upload services only from the UA to the proxy. I'm not an expert in wireless, so I'm not certain of the scope of the services we are talking about. Mid call services, for example, are not currently within the scope of CPL. However, there is nothing which prevents the CPL-upload-in-register mechanism from being used by a server to upload scripts to another server. Registrations, in general, can be used for third party controls. The From field identifies the party initiating the registration. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 11:42:24 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09143 for ; Wed, 15 Mar 2000 11:42:23 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C857A52FE; Wed, 15 Mar 2000 11:39:38 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 13FBD52FB; Wed, 15 Mar 2000 11:39:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DA56052FB for ; Wed, 15 Mar 2000 11:39:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 11:37:14 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Mar 15 11:37:13 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust251.tnt2.long-branch.nj.da.uu.net [63.25.226.251]) id QQigqk08018; Wed, 15 Mar 2000 16:37:05 GMT Message-ID: <38CFBC9F.93EC5B91@dynamicsoft.com> Date: Wed, 15 Mar 2000 11:38:55 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Benny Prijono Cc: sip@lists.research.bell-labs.com Subject: Re: Different Via grammar in the web References: <38CF8150.77A36028@theseventhson.freeserve.co.uk> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The draft is correct. The grammar is just a compendium of BNF definitions collected from various places referenced in SIP RFC. --- Igor Slepchin Benny Prijono wrote: > > Hi, > > The Via grammar specified in the Columbia.edu's SIP page > (http://www.cs.columbia.edu/sip/SIPgrammar.html#via) is different from > the one in the draft. The difference is in the extension-params, i.e. > the grammar in the web specifies that extension-params apply to the > whole Via header, while the draft specifies that extension-params apply > to each Via element. > > This is the one in the web page: > > Via = ( "Via" | "v") ":" 1#(sent-protocol sent-by *( ";" via-params ) [ > comment ] ) *(";" extension-params) > > And this is the one in the draft: > > Via = ( "Via" | "v") ":" 1#(sent-protocol sent-by *( ";" via-params ) [ > comment ] ) > via-params = ... | via-extension > > Can anybody specify which one is correct? > > cheers, > Bennylp From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 13:32:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24449 for ; Wed, 15 Mar 2000 13:32:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0C97752F5; Wed, 15 Mar 2000 13:29:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DB7DC52F7; Wed, 15 Mar 2000 13:29:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D313352F5 for ; Wed, 15 Mar 2000 13:29:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 13:27:40 EST 2000 Received: from sj-mailhub-3.cisco.com ([171.68.224.215]) by dusty; Wed Mar 15 13:27:40 EST 2000 Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA17704 for ; Wed, 15 Mar 2000 10:53:15 -0800 (PST) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id ABC15614; Wed, 15 Mar 2000 10:25:57 -0800 (PST) Message-Id: <4.2.0.58.20000315093154.00c8d2e0@lint.cisco.com> X-Sender: rmahy@lint.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Mar 2000 10:27:01 -0800 To: sip@lists.research.bell-labs.com From: Rohan Mahy Subject: clarifications on 183 and "manyfolks" drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, There is a lot of emphasis in the 183 draft on interworking with the PSTN. Very little space is devoted to the Session: QoS and Session: Security headers though. First issue/question: I can think of two ways to interpret the "Session: QoS" header. The first interpretation is that the user agent establishes QoS, and then once it has been established, it does whatever it would normally do with that 18x message (like ring or play ringback for a 180). The second is that you would use a 183 first with Session: QoS or Security to establish QoS or security, but you wouldn't do anything else about it. Then once QoS is established, you could send a new 18x message to trigger the desired behavior. (Short call flows are below, assuming RSVP) Which method is correct (if either)? INVITE --> <-- 180 Ringing (Session: QoS) [wait for QoS, then ring] <-- PATH PRACK (180)--> PATH --> RESV --> <-- 200 OK (PRACK) <-- RESV <-- RESV CONF [A plays ringback] --> RESV CONF [B alerts] or INVITE --> <-- 183 Session Progress (Session: QoS) [wait for QoS, then send 180] <-- PATH PRACK (183)--> PATH --> RESV --> <-- 200 OK (PRACK) <-- RESV <-- RESV CONF --> RESV CONF [B alerts] <-- 180 Ringing [A plays ringback] PRACK (180) --> <-- 200 OK (PRACK) Second question: Is the PRECONDITION-MET method from "manyfolks" intended to be used for all QoS enabled sessions, or just those using the DCS Gateserver method of QoS? Third question/issue: Let say that A calls UserB@group.org, and a proxy forks INVITEs in parallel to B, C, and D. If A wants to establish QoS before ringing, how does the proxy tell A about all the relevant session descriptions? It seems that if the proxy just forwarded each 18x message with its session description to A, that A would discard prior QoS relationships in favor of the most recent. (Not what we want) The proxy could send multiple session descriptions (multiple SDP bodies) in a single 18x message to A. If this is the right way to handle this situation, I think it should be more explicitly defined. If this is correct, would it be reasonable to put language in the next version of the 183 draft that says that user agents MUST be able to deal with multiple SDP bodies if they request Session: QoS? Last question/issue: If peers include a key (and crypto algorithm, key length, etc.) in the session description (for example, using a k= tag in SDP), instead of later using IKE to establish an SA, do they include "Session: Security"? thanks, -rohan From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 14:17:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13965 for ; Wed, 15 Mar 2000 14:17:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 53BE452F2; Wed, 15 Mar 2000 14:13:34 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C39CA52FB; Wed, 15 Mar 2000 14:13:33 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A9C9F52F2 for ; Wed, 15 Mar 2000 14:13:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 14:11:17 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Wed Mar 15 14:11:16 EST 2000 Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FRH00G1M9AQGA@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 15 Mar 2000 19:11:14 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FRH00J019APGY@pmismtp01.wcomnet.com>; Wed, 15 Mar 2000 19:11:13 +0000 (GMT) Received: from omzmta01.mcit.com ([166.37.194.119]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0FRH00J3M9AO7Z@pmismtp01.wcomnet.com>; Wed, 15 Mar 2000 19:11:13 +0000 (GMT) Received: from dwillispc8 ([166.44.162.170]) by omzmta01.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000315191112.QYT28186@dwillispc8>; Wed, 15 Mar 2000 19:11:12 +0000 Date: Wed, 15 Mar 2000 13:10:25 -0600 From: Dean Willis Subject: RE: SIP & RTSP interworking? In-reply-to: To: Linden deCarmo , sip@lists.research.bell-labs.com Message-id: <00fc01bf8eb2$1e9b99a0$aaa22ca6@wcomnet.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Here's what I would suggest: Build a SIP UAS that understands the RTSP end and contains stream management logic. This UAS either reinvites to establish the link to RTSP streams, or copies the RTP from each stream back into the media path for the remote UA. I know of some people(s) who are already using each approach to build a voice mail system that can use a standard RTSP server as a media store. Makes unified messaging with URL passing MUCH easier. -- dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Linden > deCarmo > Sent: Tuesday, March 14, 2000 7:27 AM > To: 'sip@lists.research.bell-labs.com' > Subject: SIP & RTSP interworking? > > > What would be the proper (or suggested) procedure to tie a SIP > session to an > RTSP session? > > What I'd like to do is setup a session with SIP (via an INVITE), then > control streaming aspects via RTSP (i.e. play, pause, stop etc.). > However, > its not clear to me how I tie the RTSP session id to the previously > established SIP session. > > Thanks. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 > > From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 14:19:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14927 for ; Wed, 15 Mar 2000 14:19:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8888C52FC; Wed, 15 Mar 2000 14:13:46 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CCCEF52F3; Wed, 15 Mar 2000 14:13:41 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0D77252F3 for ; Wed, 15 Mar 2000 14:13:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 14:11:30 EST 2000 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by dusty; Wed Mar 15 14:11:29 EST 2000 Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA26232; Wed, 15 Mar 2000 11:11:27 -0800 (PST) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id ABC16153; Wed, 15 Mar 2000 11:09:47 -0800 (PST) Message-Id: <4.2.0.58.20000315102721.00c93850@lint.cisco.com> X-Sender: rmahy@lint.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 15 Mar 2000 11:10:51 -0800 To: robert.sparks@wcom.com, ben.campbell@wcom.com From: Rohan Mahy Subject: questions on cc-framework draft Cc: sip@lists.research.bell-labs.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, The cc-framework draft proposes a modular approach to adding features. It concerns me that the framework proposes these modules, but doesn't name any except for the TRANSFER draft. Lets say that one of the next features module to be addressed is conferencing. Is CONFERENCE in this model a feature or a primitive? In many models call monitoring is a feature which uses the conference primitive. In this framework what would it look like? Would each module consist of a single draft? If conference (for example) is a primitive, does the user of the primitive have to invoke the primitive differently based on the implementation (bridge, mesh, multicast)? thanks, -rohan From owner-sip-outgoing@lists.research.bell-labs.com Wed Mar 15 14:23:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16913 for ; Wed, 15 Mar 2000 14:23:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A886C52F3; Wed, 15 Mar 2000 14:21:30 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2E6B052BB; Wed, 15 Mar 2000 14:21:29 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9F41752FF for ; Wed, 15 Mar 2000 14:21:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 14:19:59 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Wed Mar 15 14:19:58 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id OAA11397; Wed, 15 Mar 2000 14:19:53 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38CFE25B.54D62B30@vovida.com> Date: Wed, 15 Mar 2000 11:19:55 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Subject: question on sip url grammar. Content-Type: multipart/alternative; boundary="------------F166D0118678C0F5E495FF9E" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------F166D0118678C0F5E495FF9E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit A question on BNF grammar in SIP url. In BNF RFC, it is given that [ stands for 0 or 1 times the value. It is given SIP-URL = "sip:" [userinfo '@'] hostport url-parameters.... user-info = user [":"password] user = *(unreserved... ) //optional password = *(unreserved ...) //optional. so, this leads to a url as: sip::@hostport. So, with the above grammar, this is valid. is my understanding right? Also, for hostport; sip:userinfo@host:urlparms //since port is optional. Thanks much! -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------F166D0118678C0F5E495FF9E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit A question on BNF grammar in SIP url.
In BNF RFC, it is given that [       stands for 0 or 1 times the value.
It is given

SIP-URL = "sip:"  [userinfo '@'] hostport url-parameters....
user-info = user [":"password]
user = *(unreserved... )                          //optional

password = *(unreserved ...)                 //optional.

so, this leads to a url as:

sip::@hostport.                  So, with the above grammar, this is valid.
is my understanding right?

Also, for hostport;

sip:userinfo@host:urlparms            //since port is optional. 




Thanks much!



-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374

 

--------------F166D0118678C0F5E495FF9E--




From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 15 15:02:16 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02498
	for ; Wed, 15 Mar 2000 15:02:14 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 2764452FB; Wed, 15 Mar 2000 14:59:34 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9A5F052FA; Wed, 15 Mar 2000 14:59:33 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 0CE0652FB
	for ; Wed, 15 Mar 2000 14:59:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 14:57:33 EST 2000
Received: from crash.netspeak.com ([208.143.140.6]) by dusty; Wed Mar 15 14:57:32 EST 2000
Received: by crash with Internet Mail Service (5.5.2448.0)
	id ; Wed, 15 Mar 2000 14:57:31 -0500
Message-ID: 
From: Linden deCarmo 
To: "'Dean Willis'" , sip@lists.research.bell-labs.com
Subject: RE: SIP & RTSP interworking?
Date: Wed, 15 Mar 2000 14:57:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Dean,

This is an interesting suggestion, but the scenario I'm operating under is
this:

UAC<->UAC (in this case the UAC really is an RTSP server), both must
understand SIP and RTSP.  I need a way to tie the sessions between two
distinct protocols.  Is a viable alternative to embed the RTSP SETUP message
as a SIP body for the INVITE?  This would clearly associate the sessions,
but I hate to have a proprietary solution that wouldn't work with other
products that understood SIP & RTSP.

Linden deCarmo
Netspeak Corporation
902 Clint Moore Road
Suite 104
Boca Raton, FL 33487

> -----Original Message-----
> From:	Dean Willis [SMTP:dean.willis@wcom.com]
> Sent:	Wednesday, March 15, 2000 2:10 PM
> To:	Linden deCarmo; sip@lists.research.bell-labs.com
> Subject:	RE: SIP & RTSP interworking?
> 
> 
> Here's what I would suggest:
> 
> Build a SIP UAS that understands the RTSP end and contains stream
> management
> logic. This UAS either reinvites to establish the link to RTSP streams, or
> copies the RTP from each stream back into the media path for the remote
> UA.
> 
> I know of some people(s) who are already using each approach to build a
> voice mail system that can use a standard RTSP server as a media store.
> Makes unified messaging with URL passing MUCH easier.
> 
> --
> dean
> 
> > -----Original Message-----
> > From: owner-sip@lists.research.bell-labs.com
> > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Linden
> > deCarmo
> > Sent: Tuesday, March 14, 2000 7:27 AM
> > To: 'sip@lists.research.bell-labs.com'
> > Subject: SIP & RTSP interworking?
> >
> >
> > What would be the proper (or suggested) procedure to tie a SIP
> > session to an
> > RTSP session?
> >
> > What I'd like to do is setup a session with SIP (via an INVITE), then
> > control streaming aspects via RTSP (i.e. play, pause, stop etc.).
> >  However,
> > its not clear to me how I tie the RTSP session id to the previously
> > established SIP session.
> >
> > Thanks.
> >
> > Linden deCarmo
> > Netspeak Corporation
> > 902 Clint Moore Road
> > Suite 104
> > Boca Raton, FL 33487
> >
> >



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 15 15:10:06 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05517
	for ; Wed, 15 Mar 2000 15:10:04 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id A751552FA; Wed, 15 Mar 2000 15:07:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 22C6B52FD; Wed, 15 Mar 2000 15:07:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 0936652FA
	for ; Wed, 15 Mar 2000 15:07:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 15 15:05:49 EST 2000
Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Wed Mar 15 15:05:48 EST 2000
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FRH00FBUBTNK2@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Wed, 15 Mar 2000 20:05:47 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with ESMTP id <0FRH00801BTNSA@dgismtp02.wcomnet.com>;
 Wed, 15 Mar 2000 20:05:47 +0000 (GMT)
Received: from omzmta03.mcit.com ([166.37.194.121])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0FRH0077EBTMVF@dgismtp02.wcomnet.com>; Wed,
 15 Mar 2000 20:05:47 +0000 (GMT)
Received: from bacampbe ([166.35.150.71])
 by omzmta03.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000315200546.BFCN26687@bacampbe>; Wed,
 15 Mar 2000 20:05:46 +0000
Date: Wed, 15 Mar 2000 14:05:14 -0600
From: Ben Campbell 
Subject: RE: questions on cc-framework draft
In-reply-to: <4.2.0.58.20000315102721.00c93850@lint.cisco.com>
To: Rohan Mahy , robert.sparks@wcom.com
Cc: sip@lists.research.bell-labs.com
Message-id: <003d01bf8eb9$c6ced180$479623a6@topher.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
> Hi,
>
> The cc-framework draft proposes a modular approach to adding
> features.  It
> concerns me that the framework proposes these modules, but
> doesn't name any
> except for the TRANSFER draft.  Lets say that one of the next features
> module to be addressed is conferencing.  Is CONFERENCE in this model a
> feature or a primitive?

That depends on design work that hasn't been done yet in this context.
Hypothetically speaking, suppose that the requirements of conferencing do
not require any additional protocol extensions (either of syntax or
semantics) beyond TRANSFER. Then we end up with a draft that says how to use
the TRANSFER extension to accomplish conferencing. It is not an extension
per se, but it is still a useful application in the context of call control.

I suspect we are putting to many connotations on the meaning of of the word
"module". Perhaps I could have chosen a better term. The point of the draft
was not to specify a module structure in advance, but to encourage an
open-ended series of specifications for various call control applications.

>
> In many models call monitoring is a feature which uses the conference
> primitive. In this framework what would it look like?

In this case, lets assume that conference requires a real extension, and
that monitoring can be accomplished using the conference syntax and
semantics exactly as specified.. Then we have an extension for conference,
and a description of how to use that extension to accomplish call
monitoring.

>
> Would each module consist of a single draft?   If conference (for
> example)
> is a primitive, does the user of the primitive have to invoke the
> primitive
> differently based on the implementation (bridge, mesh, multicast)?
>

We did not intent to specifiy the draft structure of a module one way or
another. In the conference example, I would only expect a user to invoke it
differently if the aplication required syntactic or semantic changes. If
this is true, then another extension may be in order.

Hope this helps!

Ben Campbell.




From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 15 15:13:55 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07038
	for ; Wed, 15 Mar 2000 15:13:52 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3C72B52FD; Wed, 15 Mar 2000 15:11:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id AC26952FF; Wed, 15 Mar 2000 15:11:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id C759052FD
	for ; Wed, 15 Mar 2000 15:11:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 15:09:52 EST 2000
Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Mar 15 15:09:51 EST 2000
Received: from cisalpino.cs.columbia.edu (cisalpino.cs.columbia.edu [128.59.19.194])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA10903;
	Wed, 15 Mar 2000 15:09:50 -0500 (EST)
Received: from localhost (kns10@localhost)
	by cisalpino.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA09553;
	Wed, 15 Mar 2000 15:09:50 -0500 (EST)
Date: Wed, 15 Mar 2000 15:09:50 -0500 (EST)
From: Kundan Singh 
To: Linden deCarmo 
Cc: "'Dean Willis'" , sip@lists.research.bell-labs.com
Subject: RE: SIP & RTSP interworking?
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

--
Kundan Singh     http://www.cs.columbia.edu/~kns10

> This is an interesting suggestion, but the scenario I'm operating under is
> this:
> 
> UAC<->UAC (in this case the UAC really is an RTSP server), both must
> understand SIP and RTSP.  I need a way to tie the sessions between two
> distinct protocols.  Is a viable alternative to embed the RTSP SETUP message
> as a SIP body for the INVITE?  This would clearly associate the sessions,
> but I hate to have a proprietary solution that wouldn't work with other
> products that understood SIP & RTSP.

In that case, the UA may return the RTSP Contact: URI in (say) 3xx
response.

 UA1          UA2
     INVITE
 -------------->

   3xx Moved
   Contact:rtsp://server/resource
 <-------------

   SETUP rtsp://server/resource
 -------------->
 . . .

Since UA here understand both SIP and RTSP it should not be
a problem.

If the SIP call is already established, and UA2 wants to
switch to RTSP,  then (IMO) it may use blind call transfer
(BYE,Also:rtsp://...) to ask UA1 to connect to RTSP
server of UA2. Comments ??




From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 15 15:23:53 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11260
	for ; Wed, 15 Mar 2000 15:23:51 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 980CF52FF; Wed, 15 Mar 2000 15:21:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 168E05301; Wed, 15 Mar 2000 15:21:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id D590552FF
	for ; Wed, 15 Mar 2000 15:21:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 15:19:54 EST 2000
Received: from crash.netspeak.com ([208.143.140.6]) by dusty; Wed Mar 15 15:19:53 EST 2000
Received: by crash with Internet Mail Service (5.5.2448.0)
	id ; Wed, 15 Mar 2000 15:19:52 -0500
Message-ID: 
From: Linden deCarmo 
To: "'Kundan Singh'" 
Cc: "'Dean Willis'" , sip@lists.research.bell-labs.com
Subject: RE: SIP & RTSP interworking?
Date: Wed, 15 Mar 2000 15:19:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

I like this a lot better, but the problem I have is this, we'd like for BOTH
sessions to be active at the same time and both of your proposals require a
teardown of the SIP session.

Linden deCarmo
Netspeak Corporation
902 Clint Moore Road
Suite 104
Boca Raton, FL 33487

> -----Original Message-----
> From:	Kundan Singh [SMTP:kns10@cs.columbia.edu]
> Sent:	Wednesday, March 15, 2000 3:10 PM
> To:	Linden deCarmo
> Cc:	'Dean Willis'; sip@lists.research.bell-labs.com
> Subject:	RE: SIP & RTSP interworking?
> 
> --
> Kundan Singh     http://www.cs.columbia.edu/~kns10
> 
> > This is an interesting suggestion, but the scenario I'm operating under
> is
> > this:
> > 
> > UAC<->UAC (in this case the UAC really is an RTSP server), both must
> > understand SIP and RTSP.  I need a way to tie the sessions between two
> > distinct protocols.  Is a viable alternative to embed the RTSP SETUP
> message
> > as a SIP body for the INVITE?  This would clearly associate the
> sessions,
> > but I hate to have a proprietary solution that wouldn't work with other
> > products that understood SIP & RTSP.
> 
> In that case, the UA may return the RTSP Contact: URI in (say) 3xx
> response.
> 
>  UA1          UA2
>      INVITE
>  -------------->
> 
>    3xx Moved
>    Contact:rtsp://server/resource
>  <-------------
> 
>    SETUP rtsp://server/resource
>  -------------->
>  . . .
> 
> Since UA here understand both SIP and RTSP it should not be
> a problem.
> 
> If the SIP call is already established, and UA2 wants to
> switch to RTSP,  then (IMO) it may use blind call transfer
> (BYE,Also:rtsp://...) to ask UA1 to connect to RTSP
> server of UA2. Comments ??
> 



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 15 15:47:55 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21757
	for ; Wed, 15 Mar 2000 15:47:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 33BA75300; Wed, 15 Mar 2000 15:45:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A3AEE5302; Wed, 15 Mar 2000 15:45:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 6E0655300
	for ; Wed, 15 Mar 2000 15:45:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 15:43:56 EST 2000
Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Mar 15 15:43:55 EST 2000
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA25378;
	Wed, 15 Mar 2000 15:43:55 -0500 (EST)
Message-ID: <38CFF605.F6D91AA9@cs.columbia.edu>
Date: Wed, 15 Mar 2000 15:43:49 -0500
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: SIP web site internship listings
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I know that a number of companies are interested in hiring summer
interns for SIP-related topics. I also know there are some students
looking for such opportunities. Since this mailing list is not really
appropriate for such topics, I've started an informal list at
http://www.cs.columbia.edu/sip. Comments, additions and suggestions (to
me, not the list) are welcome.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 15 15:57:54 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25486
	for ; Wed, 15 Mar 2000 15:57:52 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id E733C5302; Wed, 15 Mar 2000 15:55:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5D94E5303; Wed, 15 Mar 2000 15:55:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id D483A5302
	for ; Wed, 15 Mar 2000 15:55:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 15:54:35 EST 2000
Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by dusty; Wed Mar 15 15:54:34 EST 2000
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA01695;
	Wed, 15 Mar 2000 12:54:32 -0800 (PST)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ABC17166;
	Wed, 15 Mar 2000 12:52:52 -0800 (PST)
Message-Id: <4.2.0.58.20000315124612.00c3d780@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 15 Mar 2000 12:53:47 -0800
To: Ben Campbell 
From: Rohan Mahy 
Subject: RE: questions on cc-framework draft
Cc: robert.sparks@wcom.com, sip@lists.research.bell-labs.com
In-Reply-To: <003d01bf8eb9$c6ced180$479623a6@topher.net>
References: <4.2.0.58.20000315102721.00c93850@lint.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Hi,

Thanks for the clarification.

So it sounds like the primary benefit of the TRANSFER method (over INVITE + 
Also) is to provide notification that the new INVITE succeeded.  Is that 
accurate?

thanks,
-rohan

At 12:05 PM 3/15/00 , Ben Campbell wrote:
> >
> > Hi,
> >
> > The cc-framework draft proposes a modular approach to adding
> > features.  It
> > concerns me that the framework proposes these modules, but
> > doesn't name any
> > except for the TRANSFER draft.  Lets say that one of the next features
> > module to be addressed is conferencing.  Is CONFERENCE in this model a
> > feature or a primitive?
>
>That depends on design work that hasn't been done yet in this context.
>Hypothetically speaking, suppose that the requirements of conferencing do
>not require any additional protocol extensions (either of syntax or
>semantics) beyond TRANSFER. Then we end up with a draft that says how to use
>the TRANSFER extension to accomplish conferencing. It is not an extension
>per se, but it is still a useful application in the context of call control.
>
>I suspect we are putting to many connotations on the meaning of of the word
>"module". Perhaps I could have chosen a better term. The point of the draft
>was not to specify a module structure in advance, but to encourage an
>open-ended series of specifications for various call control applications.
>
> >
> > In many models call monitoring is a feature which uses the conference
> > primitive. In this framework what would it look like?
>
>In this case, lets assume that conference requires a real extension, and
>that monitoring can be accomplished using the conference syntax and
>semantics exactly as specified.. Then we have an extension for conference,
>and a description of how to use that extension to accomplish call
>monitoring.
>
> >
> > Would each module consist of a single draft?   If conference (for
> > example)
> > is a primitive, does the user of the primitive have to invoke the
> > primitive
> > differently based on the implementation (bridge, mesh, multicast)?
> >
>
>We did not intent to specifiy the draft structure of a module one way or
>another. In the conference example, I would only expect a user to invoke it
>differently if the aplication required syntactic or semantic changes. If
>this is true, then another extension may be in order.
>
>Hope this helps!
>
>Ben Campbell.
>




From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 15 16:22:00 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04890
	for ; Wed, 15 Mar 2000 16:21:58 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 47C4D52F7; Wed, 15 Mar 2000 16:19:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id BFE135303; Wed, 15 Mar 2000 16:19:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 398B652F7
	for ; Wed, 15 Mar 2000 16:19:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 15 16:17:10 EST 2000
Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Wed Mar 15 16:17:10 EST 2000
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FRH001BPF4IVJ@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Wed, 15 Mar 2000 21:17:06 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with ESMTP id <0FRH00501F4I8X@pmismtp02.wcomnet.com>;
 Wed, 15 Mar 2000 21:17:06 +0000 (GMT)
Received: from omzmta03.mcit.com ([166.37.194.121])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0FRH002KEF4HVH@pmismtp02.wcomnet.com>; Wed,
 15 Mar 2000 21:17:06 +0000 (GMT)
Received: from bacampbe ([166.35.150.71])
 by omzmta03.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000315211705.CCWR26687@bacampbe>; Wed,
 15 Mar 2000 21:17:05 +0000
Date: Wed, 15 Mar 2000 15:16:33 -0600
From: Ben Campbell 
Subject: RE: questions on cc-framework draft
In-reply-to: <4.2.0.58.20000315124612.00c3d780@lint.cisco.com>
To: Rohan Mahy 
Cc: robert.sparks@wcom.com, sip@lists.research.bell-labs.com
Message-id: <005401bf8ec3$bd3cab60$479623a6@topher.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

> 
> So it sounds like the primary benefit of the TRANSFER method 
> (over INVITE + 
> Also) is to provide notification that the new INVITE succeeded.  Is that 
> accurate?
> 

That is my understanding as well.

Thanks,

Ben.



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 15 16:27:59 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07363
	for ; Wed, 15 Mar 2000 16:27:57 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id EA7E25303; Wed, 15 Mar 2000 16:25:26 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 482075304; Wed, 15 Mar 2000 16:25:25 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 5338A5303
	for ; Wed, 15 Mar 2000 16:25:10 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 16:23:38 EST 2000
Received: from redale.cisco.com ([171.71.154.68]) by dusty; Wed Mar 15 16:23:37 EST 2000
Received: from cisco.com (dhcp-171-71-147-142.cisco.com [171.71.147.142]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id NAA13181; Wed, 15 Mar 2000 13:23:00 -0800 (PST)
Message-ID: <38CFFF3E.9F4697A1@cisco.com>
Date: Wed, 15 Mar 2000 13:23:10 -0800
From: Anup Rao 
Organization: Cisco Systems
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Linden deCarmo 
Cc: "'Kundan Singh'" ,
        "'Dean Willis'" ,
        sip@lists.research.bell-labs.com
Subject: Re: SIP & RTSP interworking?
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Linden deCarmo wrote:

> I like this a lot better, but the problem I have is this, we'd like for BOTH
> sessions to be active at the same time and both of your proposals require a
> teardown of the SIP session.
>

Linden,

I still dont understand what the application is. Your first note said :

*************
What I'd like to do is setup a session with SIP (via an INVITE), then
control streaming aspects via RTSP (i.e. play, pause, stop etc.).
*************

Implying to me that there was only one session.

Your second note says:

**************
I like this a lot better, but the problem I have is this, we'd
like for BOTH
sessions to be active at the same time and both of your proposals
require a
teardown of the SIP session.
**************

Implying that there were two. (which I think makes sense).

I think there are broadly two scenarios:

a)  Sending an RTSP URL to a SIP UA as part of redirection or call termination
or transfer. The SIP session in question would be terminated.  From the SIP
point of view, it seems to make sense to put the RTSP URL in a Contact: or
Also:, exact callflows and details to be worked out.

b) Have a RTSP controlled stream as part of a conference ie an addon to an
existing or about-to-exist SIP session.
There could be a number of interesting variants to this.

One of them that follows the "SIP-UA knows RTSP" model:
You can have one SIP UA be the RTSP client (ie the owner/controller of the
stream if you will), and direct the stream to each SIP UA in the  session(could
be via multicast as well). Other UAs dont need to know anything about RTSP. In
which case SIP needs a way to inform UAs that  this new RTP stream will be added
to the session which I guess it should be able to do using re-INVITEs.
If you go with the model that the RTSP server understands SIP, then RTSP
provides a means to pass the conference ID to the RTSP server so that it can
join the SIP session and link subsequent RTSP operations to the SIP session.
Such IDs are opaque to RTSP protocol , so the usage would depend on the server
and application in question.

-Anup.

> Linden deCarmo
> Netspeak Corporation
> 902 Clint Moore Road
> Suite 104
> Boca Raton, FL 33487
>
> > -----Original Message-----
> > From: Kundan Singh [SMTP:kns10@cs.columbia.edu]
> > Sent: Wednesday, March 15, 2000 3:10 PM
> > To:   Linden deCarmo
> > Cc:   'Dean Willis'; sip@lists.research.bell-labs.com
> > Subject:      RE: SIP & RTSP interworking?
> >
> > --
> > Kundan Singh     http://www.cs.columbia.edu/~kns10
> >
> > > This is an interesting suggestion, but the scenario I'm operating under
> > is
> > > this:
> > >
> > > UAC<->UAC (in this case the UAC really is an RTSP server), both must
> > > understand SIP and RTSP.  I need a way to tie the sessions between two
> > > distinct protocols.  Is a viable alternative to embed the RTSP SETUP
> > message
> > > as a SIP body for the INVITE?  This would clearly associate the
> > sessions,
> > > but I hate to have a proprietary solution that wouldn't work with other
> > > products that understood SIP & RTSP.
> >
> > In that case, the UA may return the RTSP Contact: URI in (say) 3xx
> > response.
> >
> >  UA1          UA2
> >      INVITE
> >  -------------->
> >
> >    3xx Moved
> >    Contact:rtsp://server/resource
> >  <-------------
> >
> >    SETUP rtsp://server/resource
> >  -------------->
> >  . . .
> >
> > Since UA here understand both SIP and RTSP it should not be
> > a problem.
> >
> > If the SIP call is already established, and UA2 wants to
> > switch to RTSP,  then (IMO) it may use blind call transfer
> > (BYE,Also:rtsp://...) to ask UA1 to connect to RTSP
> > server of UA2. Comments ??
> >




From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 15 16:41:59 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13544
	for ; Wed, 15 Mar 2000 16:41:59 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 58A045301; Wed, 15 Mar 2000 16:39:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B586E5304; Wed, 15 Mar 2000 16:39:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 7FF8A5301
	for ; Wed, 15 Mar 2000 16:39:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 16:38:09 EST 2000
Received: from crash.netspeak.com ([208.143.140.6]) by dusty; Wed Mar 15 16:38:07 EST 2000
Received: by crash with Internet Mail Service (5.5.2448.0)
	id ; Wed, 15 Mar 2000 16:38:06 -0500
Message-ID: 
From: Linden deCarmo 
To: "'Anup Rao'" 
Cc: "'Kundan Singh'" ,
        "'Dean Willis'" ,
        sip@lists.research.bell-labs.com
Subject: RE: SIP & RTSP interworking?
Date: Wed, 15 Mar 2000 16:38:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Anup,

Sorry for my poor explanation.  From a global perspective, there will be one
logical session.  This logical session will consist of a SIP session and a
RTSP session which need to be united.

Given this info, your option a) would not be appropriate.

option b) is what we'd like to do.

	>If you go with the model that the RTSP server understands SIP, then
RTSP
	>provides a means to pass the conference ID to the RTSP server so
that it can
	>join the SIP session and link subsequent RTSP operations to the SIP
session.

Wow, thanks for pointing this out.  Should've noticed this before.

The text is the RFC is quite clear:

   Separation of stream control and conference initiation:
          Stream control is divorced from inviting a media server to a
          conference. The only requirement is that the conference
          initiation protocol either provides or can be used to create a
          unique conference identifier. In particular, SIP [12] or H.323
          [13] may be used to invite a server to a conference.

====

I believe my problem is solved.  Thanks!



Linden deCarmo
Netspeak Corporation
902 Clint Moore Road
Suite 104
Boca Raton, FL 33487

> -----Original Message-----
> From:	Anup Rao [SMTP:anrao@cisco.com]
> Sent:	Wednesday, March 15, 2000 4:23 PM
> To:	Linden deCarmo
> Cc:	'Kundan Singh'; 'Dean Willis'; sip@lists.research.bell-labs.com
> Subject:	Re: SIP & RTSP interworking?
> 
> 
> 
> Linden deCarmo wrote:
> 
> > I like this a lot better, but the problem I have is this, we'd like for
> BOTH
> > sessions to be active at the same time and both of your proposals
> require a
> > teardown of the SIP session.
> >
> 
> Linden,
> 
> I still dont understand what the application is. Your first note said :
> 
> *************
> What I'd like to do is setup a session with SIP (via an INVITE), then
> control streaming aspects via RTSP (i.e. play, pause, stop etc.).
> *************
> 
> Implying to me that there was only one session.
> 
> Your second note says:
> 
> **************
> I like this a lot better, but the problem I have is this, we'd
> like for BOTH
> sessions to be active at the same time and both of your proposals
> require a
> teardown of the SIP session.
> **************
> 
> Implying that there were two. (which I think makes sense).
> 
> I think there are broadly two scenarios:
> 
> a)  Sending an RTSP URL to a SIP UA as part of redirection or call
> termination
> or transfer. The SIP session in question would be terminated.  From the
> SIP
> point of view, it seems to make sense to put the RTSP URL in a Contact: or
> Also:, exact callflows and details to be worked out.
> 
> b) Have a RTSP controlled stream as part of a conference ie an addon to an
> existing or about-to-exist SIP session.
> There could be a number of interesting variants to this.
> 
> One of them that follows the "SIP-UA knows RTSP" model:
> You can have one SIP UA be the RTSP client (ie the owner/controller of the
> stream if you will), and direct the stream to each SIP UA in the
> session(could
> be via multicast as well). Other UAs dont need to know anything about
> RTSP. In
> which case SIP needs a way to inform UAs that  this new RTP stream will be
> added
> to the session which I guess it should be able to do using re-INVITEs.
> If you go with the model that the RTSP server understands SIP, then RTSP
> provides a means to pass the conference ID to the RTSP server so that it
> can
> join the SIP session and link subsequent RTSP operations to the SIP
> session.
> Such IDs are opaque to RTSP protocol , so the usage would depend on the
> server
> and application in question.
> 
> -Anup.
> 
> > Linden deCarmo
> > Netspeak Corporation
> > 902 Clint Moore Road
> > Suite 104
> > Boca Raton, FL 33487
> >
> > > -----Original Message-----
> > > From: Kundan Singh [SMTP:kns10@cs.columbia.edu]
> > > Sent: Wednesday, March 15, 2000 3:10 PM
> > > To:   Linden deCarmo
> > > Cc:   'Dean Willis'; sip@lists.research.bell-labs.com
> > > Subject:      RE: SIP & RTSP interworking?
> > >
> > > --
> > > Kundan Singh     http://www.cs.columbia.edu/~kns10
> > >
> > > > This is an interesting suggestion, but the scenario I'm operating
> under
> > > is
> > > > this:
> > > >
> > > > UAC<->UAC (in this case the UAC really is an RTSP server), both must
> > > > understand SIP and RTSP.  I need a way to tie the sessions between
> two
> > > > distinct protocols.  Is a viable alternative to embed the RTSP SETUP
> > > message
> > > > as a SIP body for the INVITE?  This would clearly associate the
> > > sessions,
> > > > but I hate to have a proprietary solution that wouldn't work with
> other
> > > > products that understood SIP & RTSP.
> > >
> > > In that case, the UA may return the RTSP Contact: URI in (say) 3xx
> > > response.
> > >
> > >  UA1          UA2
> > >      INVITE
> > >  -------------->
> > >
> > >    3xx Moved
> > >    Contact:rtsp://server/resource
> > >  <-------------
> > >
> > >    SETUP rtsp://server/resource
> > >  -------------->
> > >  . . .
> > >
> > > Since UA here understand both SIP and RTSP it should not be
> > > a problem.
> > >
> > > If the SIP call is already established, and UA2 wants to
> > > switch to RTSP,  then (IMO) it may use blind call transfer
> > > (BYE,Also:rtsp://...) to ask UA1 to connect to RTSP
> > > server of UA2. Comments ??
> > >



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 00:33:54 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07234
	for ; Thu, 16 Mar 2000 00:33:53 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 006285307; Thu, 16 Mar 2000 00:24:44 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 644BD5305; Thu, 16 Mar 2000 00:24:20 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 19D4152FB
	for ; Wed, 15 Mar 2000 10:25:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 15 10:24:57 EST 2000
Received: from kickme.cisco.com ([198.92.30.42]) by dusty; Wed Mar 15 10:24:56 EST 2000
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA03464;
	Wed, 15 Mar 2000 07:12:40 -0800 (PST)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ABC13888;
	Wed, 15 Mar 2000 07:23:11 -0800 (PST)
Message-Id: <4.2.0.58.20000315070508.00c30100@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 15 Mar 2000 07:24:16 -0800
To: Jonathan Rosenberg 
From: Rohan Mahy 
Subject: Re: Provisional Response Draft
Cc: Anders Kristensen , kkrama@research.att.com,
        sip@lists.research.bell-labs.com
In-Reply-To: <38CF1450.ED323ED6@dynamicsoft.com>
References: <200003091921.AAY16299@imop.cisco.com>
 <4.2.0.58.20000310091028.00cb23c0@lint.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Hi,

Thanks for your reply.  I've read the "Guidelines" draft, and I respect 
your philosophy.  Your point was driven home after seeing the flurry of new 
methods proposed recently (SUBSCRIBE/NOTIFY, TRANSFER, PRECONDITIONS).

I was hoping the group could come to some compromise to preserve message 
efficiency, but at this point it does not seem worth the effort.

thanks,
-rohan

At 08:40 PM 3/14/00 , Jonathan Rosenberg wrote:
>Rohan Mahy wrote:
> >
> > Hi,
> >
> > At 12:09 PM 3/9/00 , Jonathan Rosenberg wrote:
> > >All requests are responded to. period.
> >
> > I never debated this.  The user agents will always have an opportunity to
> > respond.
> >
> > I agree with kkrama@research.att.com, that proxies shouldn't keep state for
> > methods they don't understand.  They can simply forward messages for these
> > unknown methods on to the user agents or the next proxy.
>
>If you want to build your proxy that way, fine. But I think it is asking
>to much to mandate that unknown methods be forwarded statelessly. The
>spec as written does not mandate this.
>
>
> > So what I hear Jonathan saying is that because some proxies MIGHT keep
> > state for new methods, then we need 200 OK, so that we don't break them.
> > Correct?  I am personally curious how many proxies would break.
> >
> > Also, I hear Jonathan saying that new methods should be processed in the
> > same way, and that this encourages simplicity.  Aside from the comment
> > above, is there another motivation for this?
>
>Yes. It leads to a clean architectural implementation. It means I can
>build a base transaction mechanism that handles retransmissions and
>provisional responses and stuff without detailed message semantics, and
>then build semantic processing on top of this. It is this same
>motivation which has led me to conclude that transactions must be kept
>independent; so that, for example, if I send a BYE for an INVITE that
>hasn't been answered, the UAS should still answer the INVITE.
>
>The issue of allowing stateful proxies for unknown methods is a big one
>as well. It means that SIPs routing and searching capabilities can be
>reused for other services (i.e., other methods) with existing proxies. I
>think this is not to be dismissed so lightly.
>
>While there are clear advantages to keeping the 200 OK to PRACK, the
>only advantage I have heard to date for dropping it is message
>efficiency. In general, I firmly believe that generality and broad
>applicability are far more important design goals than message
>efficiency. I discuss this in more detail in the draft I recently
>submitted entitled "Guidelines for Authors of SIP Extensions".
>
>-Jonathan R.




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 02:45:56 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07148
	for ; Thu, 16 Mar 2000 02:45:56 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id EE9E452F4; Thu, 16 Mar 2000 02:43:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 59D3452FF; Thu, 16 Mar 2000 02:43:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 320D352F4
	for ; Thu, 16 Mar 2000 02:43:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 02:42:05 EST 2000
Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Mar 16 02:42:02 EST 2000
Received: from dynamicsoft.com (1Cust213.tnt1.freehold.nj.da.uu.net [63.17.113.213])
	by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA13104;
	Thu, 16 Mar 2000 02:41:57 -0500 (EST)
Message-ID: <38D091C8.B596E724@dynamicsoft.com>
Date: Thu, 16 Mar 2000 02:48:24 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne 
Cc: sip@lists.research.bell-labs.com, Robert.Sparks@wcom.com
Subject: Re: Comments on transfer draft (sparks-sip-cc-transfer-00)
References: <38C9406B.DD547641@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Henning Schulzrinne wrote:
> 
> A few low-level comments:
> 
> - I'm not sure "TRANSFER" is the right verb here, since transfer implies
> moving something from one place to another. All TRANSFER does is
> effectively ask the recipient to send another INVITE. It would be nice
> if the same action could be used (say) for mesh conferences. 

It would be nice, and indeed this is the motivation which led us to use
Also for both in the original call control draft. Problem is, a full
mesh conference requires much more than just "send an INVITE to
so-and-so". It requires a fair amount of synchronization and additional
semantics, beyond what is needed for transfer. 

However, I agree that the mechanism might have other uses besides
transfer, so something more functional would be nice. I also agree that
we should figure out the primitive functions we need to accomplish the
call control capabilities, and then specify extensions for the
primitives rather than the services. The services themselves can then be
described through informational documents that reference the extensions.
I think the idea proposed in the framework, of basically breaking call
control into separate pieces, is probably a good idea.


> - Using TRANSFER instead of INVITE with Also does have one major
> disadvantage, since the originator of the request will retransmit with
> T2 (4 seconds).

An excellent point. Another advantage of BYE/Also over a new method is
that it saves two messages (separate TRANSFER/response and BYE/response)
when implementing your basic blind transfer.

However, I think a new method is better, in the end. It becomes
increasingly complex to figure out how to handle an INVITE or BYE
request if it can be filled with tons of headers, each doing a separate
thing. Also, by overloading BYE, the interpretation of the response
becomes harder. If the response to a BYE/Also was 400, was this because
the transfer failed, or because the BYE itself was bad? Using a specific
method makes it clear what the response means. Also, using a new method
means that the same mechanism can support unattended transfers, blind
transfers, and a bunch of others. 

So, if we go by the philosophy in the "Guidelines for Authors of SIP
Extensions" draft, generality and flexibility wins over efficiency,
which speaks for a new method.


> 
> - According to the rules for feature names, IETF-based extensions are
> single words, to avoid any possible confusion with proprietary
> extensions having inverted domain names. Thus, it should probably just
> be Requires: transfer rather than cc.transfer. (On the other hand, it's
> not clear this is needed at all - we don't need Require for new methods,
> since they already have a mechanism to say "sorry, je ne comprend pas").

Require is definitely not needed. This is an advantage to new methods as
opposed to new headers in an existing method. 

It would be really nice, however, to know ahead of time whether all
parties supported transfer (and any other mechanisms to be defined). The
Supported extension draft defines a way in which the UAC would indicate
to the UAS that it knows the new mechanism, but that draft does not
mandate that a UAS return a Supported header in the response to any
method (only OPTIONS). We can add this, and say that if a UAS receives a
request (with any method) with a Supported header, it should place a
Supported header in the response and list those features it knows. This
would allow a caller to know whether the called party supports transfer
before trying it. Thoughts?

I noted the following in the transfer draft:
> Explicit non-Requirements
> 
>    1. There is no requirement for the Transfer Target to be notified
>    that he is receiving an INVITE as the result of a TRANSFER request
>    (see comment 2).

Why? I really liked the idea of knowing that this call was the result of
a transfer, and knowing who the transferor was. A UA can always ignore
this information, and then get the basic service you have today. 


The document says TRANSFER can't have a body. Why not? I can think of
some cool uses for this down the road. Why rule it out? 

The draft says:
> UA receiving a well-formed TRANSFER request SHOULD request approval
>    from the user to proceed. In the absence of that request, or upon
>    receiving approval from the user, the UA MUST submit an INVITE to
>    the resource identified by the Transfer-To: header using the Call-ID
>    from the TRANSFER request.

This thing about the Call-ID being copied from the TRANSFER seemed odd.
Why is that? If you wanted to accomplish this, it seems better to have
the URL in the Transfer-To header contain the Call-ID as a URL
parameter. In other words, why not do:

Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays


Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 03:01:29 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13224
	for ; Thu, 16 Mar 2000 03:01:26 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 7F2355304; Thu, 16 Mar 2000 02:59:19 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id EFCBD5305; Thu, 16 Mar 2000 02:59:18 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 7A01B5304
	for ; Thu, 16 Mar 2000 02:59:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 16 02:58:14 EST 2000
Received: from mailgate.lgcit.com ([150.150.83.41]) by dusty; Thu Mar 16 02:58:13 EST 2000
Received: (from root@localhost)
	by mailgate.lgcit.com (8.9.3/8.9.3) id RAA09042
	for sip@lists.research.bell-labs.com.procmail; Thu, 16 Mar 2000 17:08:38 +0900 (KST)
Received: from mail.lgcit.com (mail.lgcit.com [150.150.64.170])
	by mailgate.lgcit.com (8.9.3/8.9.3) with ESMTP id RAA09036
	for ; Thu, 16 Mar 2000 17:08:37 +0900 (KST)
Received: from mail.lgcit.com (leslie.lgcit.com [150.150.87.76]) by mail.lgcit.com (8.8.8/8.8.8) with ESMTP id QAA13123 for ; Thu, 16 Mar 2000 16:53:46 +0900 (KST)
Message-ID: <38D093F2.F0495005@mail.lgcit.com>
Date: Thu, 16 Mar 2000 16:57:38 +0900
From: Dohoon Kim 
Reply-To: leslie@lgcit.com
Organization: Networked Multimedia, Innovation Center, LGCIT
X-Mailer: Mozilla 4.51 [ko] (Win95; I)
X-Accept-Language: ko,en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: Question on RTP
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


The caller lists the codecs avaiable in the session description in an
INIVTE,
then the callee lists the codecs which can be supported among them.

If multiple codec is available in a media stream, such as

m=audio 1 RTP/AVP 0 1

which codec should be selected by caller,

and how can the callee know which codec is selected?




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 05:36:01 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02981
	for ; Thu, 16 Mar 2000 05:36:00 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 2E3B952EE; Thu, 16 Mar 2000 05:33:19 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A770A52FF; Thu, 16 Mar 2000 05:33:18 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 8FF7052EE
	for ; Thu, 16 Mar 2000 05:33:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 16 05:32:13 EST 2000
Received: from qnsgs000.nortel.com ([47.211.0.31]) by dusty; Thu Mar 16 05:32:13 EST 2000
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qnsgs000.nortel.com; Thu, 16 Mar 2000 10:31:26 +0000
Received: by zhard00m.europe.nortel.com 
          with Internet Mail Service (5.5.2650.21) id ;
          Thu, 16 Mar 2000 10:31:24 -0000
Message-ID: <33E324D95F44D311AA3E00204840075B550353@zhard00e.europe.nortel.com>
From: "Mark Gibson" 
To: "'mpls@uu.net'" 
Cc: "'sip@lists.research.bell-labs.com'" 
Subject: updated draft
Date: Thu, 16 Mar 2000 10:31:20 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF8F32.C7261804"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

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_01BF8F32.C7261804
Content-Type: text/plain

All

The updated version of the draft I presented in Washington is now available
at:

http://www.ietf.org/internet-drafts/draft-gibson-manage-mpls-qos-01.txt
 

The draft has essentially been re-organised and the emphasis on the SIP
solution is now downplayed.
I do not intend to re-present this in Adelaide as there is some ongoing work
to better define and generalise the control layer protocol initially
described in draft-gibson-sip-qos-resv-00.txt. 

Naturally I'll only pursue a WG timeslot once this work is complete and
whole.

Mark

------_=_NextPart_001_01BF8F32.C7261804
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






updated draft




All




The updated version of the draft I =
presented in Washington is now available at:




http://www.ietf.org/internet-drafts/draft-gibson-manage-m=
pls-qos-01.txt




The draft has essentially been =
re-organised and the emphasis on the SIP solution is now =
downplayed.

I do not intend to re-present this in =
Adelaide as there is some ongoing work to better define and generalise =
the control layer protocol initially described in =
draft-gibson-sip-qos-resv-00.txt. 



Naturally I'll only pursue a WG =
timeslot once this work is complete and whole.




Mark





------_=_NextPart_001_01BF8F32.C7261804--



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 09:12:06 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15563
	for ; Thu, 16 Mar 2000 09:12:05 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 0581B52F6; Thu, 16 Mar 2000 09:09:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 782485305; Thu, 16 Mar 2000 09:09:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 58B7652F6
	for ; Thu, 16 Mar 2000 09:09:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 16 09:07:23 EST 2000
Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Thu Mar 16 09:07:22 EST 2000
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FRI00A4EPVZE5@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Thu, 16 Mar 2000 14:07:11 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FRI00I01PVY7F@dgismtp01.wcomnet.com> for
 sip@lists.research.bell-labs.com; Thu, 16 Mar 2000 14:07:11 +0000 (GMT)
Received: from omzmta01.mcit.com ([166.37.214.7])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FRI00H9KPVX46@dgismtp01.wcomnet.com> for
 sip@lists.research.bell-labs.com; Thu, 16 Mar 2000 14:07:10 +0000 (GMT)
Received: from dwillispc8 ([166.35.148.173])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000316140709.GHIS28186@dwillispc8> for
 ; Thu, 16 Mar 2000 14:07:09 +0000
Date: Thu, 16 Mar 2000 08:06:23 -0600
From: Dean Willis 
Subject: Agenda closing for Adelaide meeting
To: IETF SIP 
Message-id: <000001bf8f50$d052b4a0$ad9423a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


I have to have the agenda in by noon Friday, so we'll be closing teh request
queue and finalizing the agenda.


The  slot request list at:
http://www.softarmor.com/sipwg/meets/IETF47/agenda-requests.html

contains the following as of  20000315-1330 USCST:

* James M. Polk. ID on Priority, Flash Override. jmpolk@cisco.com . Request
received 2/22/00, 1256 CST.
* Dean Willis SIP-T Approach and Status placeholder. dean.willis@wcom.com
3/2/00, 2100 CST
* Shinichi Baba draft-itsumo-sip-mobility-req-00.txt,
sbaba@tari.toshiba.com 3/6/00, 1522 CST
* Adam Roach of Gonzalo Camarillo, SIP-T ISUP MIME. adam.roach@ericsson.com,
3/6/00 1836 CST gonzalo.camarillo@ericsson.com
* Adam Roach, SUBSCRIBE/NOTIFY, adam.roach@ericsson.com, 3/6/00 1836 CST
* Jonathan Rosenberg, draft-lennox-sip-reg-payload-00, 3/7/00, 1100 CST
* Gonzalo Camarillo, draft-camarillo-sip-isup-bcp-00.txt. 3/7/00 0546 CST
* Steven Donovam, INFO draft, 3/9/00 1700 CST
* Steven Donovan, Session Timer draft, 3/9/00 1700 CST
* Steven Donovan, 183 and early media status update, 3/9/00 1700 CST

I'm sure I'm missing a few things. If you've asked for a slot request,
please check the list and make sure you're on it. If not, notify me ASAP.

--
Dean Willis
SIP WG co-chair.




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 09:42:01 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26978
	for ; Thu, 16 Mar 2000 09:42:00 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id DEFC952FF; Thu, 16 Mar 2000 09:39:25 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 430165306; Thu, 16 Mar 2000 09:39:25 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id DE4DA52FF
	for ; Thu, 16 Mar 2000 09:39:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 09:38:26 EST 2000
Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Thu Mar 16 09:38:25 EST 2000
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FRI000BKRC04X@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Thu, 16 Mar 2000 14:38:24 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with ESMTP id <0FRI00K01RC073@dgismtp02.wcomnet.com>;
 Thu, 16 Mar 2000 14:38:24 +0000 (GMT)
Received: from omta3.mcit.com ([166.37.204.5])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0FRI00IBSRBZQV@dgismtp02.wcomnet.com>; Thu,
 16 Mar 2000 14:38:23 +0000 (GMT)
Received: from sipdev4 ([166.35.153.153])
 by omta3.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000316143512.EXKH3044@sipdev4>; Thu, 16 Mar 2000 14:35:12 +0000
Date: Thu, 16 Mar 2000 08:30:03 -0600
From: Robert Sparks 
Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)
In-reply-to: <38D091C8.B596E724@dynamicsoft.com>
To: "'Jonathan Rosenberg'" ,
        "'Henning Schulzrinne'" 
Cc: sip@lists.research.bell-labs.com
Reply-To: Robert.Sparks@wcom.com
Message-id: <001301bf8f54$1ecc6600$999923a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes:
> However, I agree that the mechanism might have other uses besides
> transfer, so something more functional would be nice. I also 
> agree that
> we should figure out the primitive functions we need to accomplish the
> call control capabilities, and then specify extensions for the
> primitives rather than the services. The services themselves 
> can then be
> described through informational documents that reference the 
> extensions.
> I think the idea proposed in the framework, of basically breaking call
> control into separate pieces, is probably a good idea.

I agree with specifying primatives rather than services.

> I noted the following in the transfer draft:
> > Explicit non-Requirements
> > 
> >    1. There is no requirement for the Transfer Target to be notified
> >    that he is receiving an INVITE as the result of a 
> TRANSFER request
> >    (see comment 2).
> 
> Why? I really liked the idea of knowing that this call was 
> the result of
> a transfer, and knowing who the transferor was. A UA can always ignore
> this information, and then get the basic service you have today. 

I really like the idea too. Perhaps as part of the work right now we
can capture knowing that the call was the result of a transfer (by adding
an informational header to the invite - something that doesn't change
the invite semantics), but my preference is to wait for direction from
the SIP security task folks before addressing telling the transfer target
who the transferor was.

> The document says TRANSFER can't have a body. Why not? I can think of
> some cool uses for this down the road. Why rule it out? 

For consistency of implementation? (btw - One of those cool uses could be
providing the identity of the transferor.) The presence of a body 
would likely affect the semantics of the operation (if it were honored,
hence the consistency comment) through side-effects if not directly,
so would it not make sense for the addition of a body to the base
method be an actual extention? Perhaps the restriction should be
loosened to allow any body which if processed, would not affect
the behavior of the request?

> 
> The draft says:
> > UA receiving a well-formed TRANSFER request SHOULD request approval
> >    from the user to proceed. In the absence of that request, or upon
> >    receiving approval from the user, the UA MUST submit an INVITE to
> >    the resource identified by the Transfer-To: header using 
> the Call-ID
> >    from the TRANSFER request.
> 
> This thing about the Call-ID being copied from the TRANSFER 
> seemed odd.
> Why is that? If you wanted to accomplish this, it seems better to have
> the URL in the Transfer-To header contain the Call-ID as a URL
> parameter. In other words, why not do:
> 
> Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays

Interesing thought! Can we explore your thinking more here?
Using this, the TRANSFER would look like

TRANSFER sip:transferee@transfereehost
Transfer-To: sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
Call-ID: abc@eeOrorhost

Are you suggesting the subsequent invite look like this?

INVITE sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
Call-ID: def@eehost

What would the request-URI parameter be used for then? I'm 
not seeing obvious uses outside of event-logging.

On reflection, I specified this copy because it resulted in
a call-leg tuple that looked the same as it would have after
a sip-cc-01 blind transfer. The motivation that draft had for
this behavior may not apply here. Is there any value in keeping
the Call-ID information accross this function (thinking of it
as PLEASEINVITE instead of TRANSFER)?

RjS



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 10:42:12 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18776
	for ; Thu, 16 Mar 2000 10:42:11 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id CB4315305; Thu, 16 Mar 2000 10:39:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 4EDB55309; Thu, 16 Mar 2000 10:39:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 5FEA65305
	for ; Thu, 16 Mar 2000 10:39:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 10:37:59 EST 2000
Received: from cclinf.polito.it ([130.192.9.6]) by dusty; Thu Mar 16 10:37:58 EST 2000
Received: from athena.polito.it (cclinf19.polito.it [130.192.9.39])
	by cclinf.polito.it (8.9.3+Sun/8.9.1) with ESMTP id QAA12997
	for ; Thu, 16 Mar 2000 16:37:48 +0100 (MET)
Message-ID: <38D0FFD1.E121A1B@athena.polito.it>
Date: Thu, 16 Mar 2000 16:37:54 +0100
From: Laurent-Walter Goix 
Organization: Politecnico di Torino / INSA de Lyon
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: Comments on draft-ietf-sip-call-flows-00
References: <33E324D95F44D311AA3E00204840075B550353@zhard00e.europe.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all

I have some comments about the draft-ietf-sip-call-flows-00.txt. Seems
to be some errors in some call scenarios:

- page 110 (SIP->PSTN, bad PSTN number): as NGW1 receive from Proxy
To:, doesn't it try an IAM (F5) with
CdPN=+44-1234,NPI=E.164,NOA=International (or something like that)

- page 138(Unsuccessful PSTN->SIP): what is said above the figure (NGW1
sends a REL message back to A when receiving the 600 Busy Everywhere
error from Proxy) is incompatible with both the figure and the call
flows description: shouldn't the gateway send the REL message?

- page 90(successful SIP->PSTN): how could user A send a PRACK message
with the private number of B (F13) since Proxy nerver sended it this
URL?
Even if he could become it anyhow, might he send it a later INVITE (as
he remembered this address in his "SIP address book") at this private
number (How does the "globalization of the SIP URL" work is that case,
if any?). Doesn't it raise the problem of a privacy or access violation?
(even the PBX's  private numbers which don't correspond to any public
number may be reachable directly)

Please correct me where I'm wrong.

Laurent-Walter Goix




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 11:03:07 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25800
	for ; Thu, 16 Mar 2000 11:03:02 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id B6995530A; Thu, 16 Mar 2000 10:59:36 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 2CA35530B; Thu, 16 Mar 2000 10:59:36 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 1B364530A
	for ; Thu, 16 Mar 2000 10:59:09 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 10:57:55 EST 2000
Received: from qnsgs000.nortel.com ([47.211.0.31]) by dusty; Thu Mar 16 10:57:53 EST 2000
Received: from zhard00m.europe.nortel.com (actually zhard00m) 
          by qnsgs000.nortel.com; Thu, 16 Mar 2000 15:57:16 +0000
Received: by zhard00m.europe.nortel.com 
          with Internet Mail Service (5.5.2650.21) id ;
          Thu, 16 Mar 2000 15:57:13 -0000
Message-ID: <61ABD11436FED21192440000F81F3E3602BE65DC@nwcwi1a.europe.nortel.com>
From: "Michael O'Doherty" 
To: sip@lists.research.bell-labs.com
Subject: New I-D available soon - Java enhanced SIP
Date: Thu, 16 Mar 2000 15:57:03 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF8F60.4B478938"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

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_01BF8F60.4B478938
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi,

I've posted an Internet Draft to the internet draft archives which describes
an extension to SIP to build on some of the strengths of Java, the JVM
concept and Java Mobile agents.
 
It is not intended to discuss this at Adelaide as it is an initial draft but
I would be interested in getting feedback and comments from anybody who
takes a look at it.

The ID defines the extension to the SIP protocol and describes how it is
intended to:

- extend SIP messages to carry Java applets or Java applets plus their state
and runtime contexts - in other words  Java mobile agents (or URLs to either
the applet or the Java Mobile agent)

- to define a Java SIP API which will allow the Java applet or Java Mobile
Agent interact with the receiving host system and receiving SIP client

- to extend the SIP client so that the Java applet or Java Mobile Agent is
run before any other actions are taken on the receipt of a message by the
receiving host SIP client.



It also includes security measures to allow a client to be configured to
enable and disable certain actions between the JVM running the Java applet
or the Java mobile agent virtual machine running the Java Mobile Agent in
the message and the clients SIP client and host system.

Cheers,

Mick O'Doherty
Nortel Networks

----------------------------------------------------------------------------
---------
A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Java enhanced SIP (JES)
	Author(s)	: M. O'Doherty
	Filename	: draft-odoherty-sip-java-enhanced-00.txt
	Pages		: 9
	Date		: 08-Mar-00
	
This document defines an extension to the SIP [2] protocol to do a 
number of things - to extend SIP messages to carry Java applets or 
Java Mobile Agents, to define a Java SIP API which will allow the 
Java applet or Java Mobile Agent to interact with the receiving 
host system and to extend the SIP protocol client so that the Java 
applet or Java Mobile Agent is run before any other actions are 
taken on the receipt of a message by the receiving host SIP 
client.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-odoherty-sip-java-enhanced-00.txt

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-odoherty-sip-java-enhanced-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
----------------------------------------------------------------------------
-----------------------------------

------_=_NextPart_001_01BF8F60.4B478938
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






New I-D available soon - Java enhanced SIP




Hi,




I've posted an Internet Draft =
to the internet draft archives which describes an extension to SIP to =
build on some of the strengths of Java, the JVM concept and Java Mobile =
agents.



 

It is not intended to discuss =
this at Adelaide as it is an initial draft but I would be interested in =
getting feedback and comments from anybody who takes a look at =
it.



The ID defines the extension =
to the SIP protocol and describes how it is intended to:




- extend SIP messages to carry =
Java applets or Java applets plus their state and runtime contexts - in =
other words  Java mobile agents (or URLs to either the applet or =
the Java Mobile agent)



- to define a Java SIP API =
which will allow the Java applet or Java Mobile Agent interact with the =
receiving host system and receiving SIP client



- to extend the SIP client so =
that the Java applet or Java Mobile Agent is run before any other =
actions are taken on the receipt of a message by the receiving host SIP =
client.







It also =
includes security measures to allow a client to be configured to enable =
and disable certain actions between the JVM running the Java applet or =
the Java mobile agent virtual machine running the Java Mobile Agent in the message and the clients SIP =
client and host system.



Cheers,




Mick =
O'Doherty

Nortel =
Networks




--------------------------------------------------------------------=
-----------------

A New Internet-Draft is available =
from the on-line Internet-Drafts directories.






        Title   =
        : Java enhanced SIP =
(JES)

        Author(s)       : M. =
O'Doherty

        Filename        : =
draft-odoherty-sip-java-enhanced-00.txt

        Pages   =
        : 9

        Date    =
        : 08-Mar-00

       =20

This document defines an extension to =
the SIP [2] protocol to do a 

number of things - to extend SIP =
messages to carry Java applets or 

Java Mobile Agents, to define a Java =
SIP API which will allow the 

Java applet or Java Mobile Agent to =
interact with the receiving 

host system and to extend the SIP =
protocol client so that the Java 

applet or Java Mobile Agent is run =
before any other actions are 

taken on the receipt of a message by =
the receiving host SIP 

client.




A URL for this Internet-Draft =
is:

http://www.ietf.org/internet-drafts/draft-odoherty-sip=
-java-enhanced-00.txt




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-odoherty-sip-java-enhanced-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

---------------------------------------------------------=
------------------------------------------------------





------_=_NextPart_001_01BF8F60.4B478938--



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 11:05:55 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26963
	for ; Thu, 16 Mar 2000 11:05:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 93C4C530D; Thu, 16 Mar 2000 10:59:45 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D8EE55309; Thu, 16 Mar 2000 10:59:40 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 5E8B25309
	for ; Thu, 16 Mar 2000 10:59:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 10:58:29 EST 2000
Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Mar 16 10:58:29 EST 2000
Received: from dynamicsoft.com ([216.89.83.2])
	by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA13760;
	Thu, 16 Mar 2000 10:54:20 -0500 (EST)
Message-ID: <38D10531.F2FA3766@dynamicsoft.com>
Date: Thu, 16 Mar 2000 11:00:49 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: leslie@lgcit.com
Cc: sip@lists.research.bell-labs.com
Subject: Re: Question on RTP
References: <38D093F2.F0495005@mail.lgcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Dohoon Kim wrote:
> 
> The caller lists the codecs avaiable in the session description in an
> INIVTE,
> then the callee lists the codecs which can be supported among them.
> 
> If multiple codec is available in a media stream, such as
> 
> m=audio 1 RTP/AVP 0 1
> 
> which codec should be selected by caller,

Any one they want.

> 
> and how can the callee know which codec is selected?

By the payload type number in the RTP packets.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 11:09:27 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28266
	for ; Thu, 16 Mar 2000 11:09:27 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id D05925309; Thu, 16 Mar 2000 11:05:40 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 030EB530F; Thu, 16 Mar 2000 11:05:39 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 71CEF5309
	for ; Thu, 16 Mar 2000 11:05:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 16 11:04:07 EST 2000
Received: from prima.time.saic.com ([205.153.241.31]) by dusty; Thu Mar 16 11:04:06 EST 2000
Received: from degas.time.saic.com (degas.time.saic.com [205.153.241.32])
	by prima.time.saic.com (8.9.3/8.8.5) with ESMTP id LAA06420;
	Thu, 16 Mar 2000 11:04:18 -0500 (EST)
Message-Id: <200003161604.LAA06420@prima.time.saic.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: "James M. Polk" 
Cc: sip@lists.research.bell-labs.com
Subject: Re: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt 
In-Reply-To: Your message of "Tue, 14 Mar 2000 17:39:01 CST."
             <4.1.20000314172759.00c0c9f0@diablo.cisco.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Thu, 16 Mar 2000 11:00:46 -0500
From: Ken Carlberg 
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA28266


> Like so many others -- I'm letting you know of a new Draft 
> (draft-polk-sip-mlpp-mapping-00.txt) that addresses 'Multi-Level 
> Precedence and Preemption' in SIP environments. Specifically it provides 
> the background of existing Voice Networks that have specific requirements 
> for differentiating Classes of Voice traffic, not just Voice from all other 
> types of traffic. This I-D also recommends the ability to mandate the 
> Header-Field 'Priority:' during session set-up within a domain (analagous 
> to how the existing MLPP  networks function today), but with the obvious 
> advantages of IP (vs. TDM). I know that should get some attention by itself.

Nice piece of work, however I have some concerns.  First, some background 
info.

Within the U.S., MLPP (ANSI-T1.619A) is only available on some military 
systems like Autovon.  It is _illegal_ to use it (i believe by mandate of 
FCC) in the U.S. PSTN because it involves *preemption* of calls.  I don't 
believe there is another country that allows its PSTN to preempt existing 
calls, though I would appreciate being corrected on this.  So I have some
concern about mandating SIP receivers to recognize MLPP if it can only
be used within closed-loop/non-public systems.  

On the other hand, the SS7 system of Sprint, MCI, and AT&T support 
ANSI-T1.631-1993 -- High Probability of Completion (HPC), in which 
emergency calls are marked accordingly and are queued to improve the
*probability* that their call will be completed.  I.e., no preemption
is generated by the emergency call.  

Part of the reason I bring this up is that if one is going to specify a 
more definitive description of priority for SIP, as well as the action to 
be taken, then I would prefer a document that included both preemptive and 
non-preemptive values.  I agree there is a need/marketplace for SIP-MLPP, 
but I'd prefer to see a more encompasing document.

I'm curious as to the position on this subject of the SIP chairs.  Does
the group advance a document that is not (and cannot be) supported by 
the PSTN?

cheers,

-ken






From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 11:21:56 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03336
	for ; Thu, 16 Mar 2000 11:21:56 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 36A93530B; Thu, 16 Mar 2000 11:19:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A64E9530E; Thu, 16 Mar 2000 11:19:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id BA0D3530B
	for ; Thu, 16 Mar 2000 11:19:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 16 11:17:06 EST 2000
Received: from mailgate.fore.com ([169.144.68.6]) by dusty; Thu Mar 16 11:17:04 EST 2000
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12])
	by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA00832;
	Thu, 16 Mar 2000 11:17:00 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
	by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA11071;
	Thu, 16 Mar 2000 11:17:03 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 16 Mar 2000 11:12:43 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF208AF8@whq-msgusr-02.fore.com>
From: "Rosen, Brian" 
To: "'Ken Carlberg'" ,
        "James M. Polk" 
Cc: sip@lists.research.bell-labs.com
Subject: RE: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt 
Date: Thu, 16 Mar 2000 11:16:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA03336

Perhaps I'm mistaken, but I believe the PSTN actually does
implement MLPP, but it is only used by the government in
emergency situations.

I do agree that Emergency calls have to be differentiated 
from Premptable calls.  

On your final thread, it should certainly be possible to define
an extension to SIP that is not useful in the PSTN; extensions
that are useful only within an enterprise for example should
be acceptable, or in the home, as well as something like MLPP 
which is useful within a government communications system.

Brian

> -----Original Message-----
> From: Ken Carlberg [mailto:carlberg@time.saic.com]
> Sent: Thursday, March 16, 2000 11:01 AM
> To: James M. Polk
> Cc: sip@lists.research.bell-labs.com
> Subject: Re: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt 
> 
> 
> 
> > Like so many others -- I'm letting you know of a new Draft 
> > (draft-polk-sip-mlpp-mapping-00.txt) that addresses 'Multi-Level 
> > Precedence and Preemption' in SIP environments. 
> Specifically it provides 
> > the background of existing Voice Networks that have 
> specific requirements 
> > for differentiating Classes of Voice traffic, not just 
> Voice from all other 
> > types of traffic. This I-D also recommends the ability to 
> mandate the 
> > Header-Field 'Priority:' during session set-up within a 
> domain (analagous 
> > to how the existing MLPP  networks function today), but 
> with the obvious 
> > advantages of IP (vs. TDM). I know that should get some 
> attention by itself.
> 
> Nice piece of work, however I have some concerns.  First, 
> some background 
> info.
> 
> Within the U.S., MLPP (ANSI-T1.619A) is only available on 
> some military 
> systems like Autovon.  It is _illegal_ to use it (i believe 
> by mandate of 
> FCC) in the U.S. PSTN because it involves *preemption* of 
> calls.  I don't 
> believe there is another country that allows its PSTN to 
> preempt existing 
> calls, though I would appreciate being corrected on this.  So 
> I have some
> concern about mandating SIP receivers to recognize MLPP if it can only
> be used within closed-loop/non-public systems.  
> 
> On the other hand, the SS7 system of Sprint, MCI, and AT&T support 
> ANSI-T1.631-1993 -- High Probability of Completion (HPC), in which 
> emergency calls are marked accordingly and are queued to improve the
> *probability* that their call will be completed.  I.e., no preemption
> is generated by the emergency call.  
> 
> Part of the reason I bring this up is that if one is going to 
> specify a 
> more definitive description of priority for SIP, as well as 
> the action to 
> be taken, then I would prefer a document that included both 
> preemptive and 
> non-preemptive values.  I agree there is a need/marketplace 
> for SIP-MLPP, 
> but I'd prefer to see a more encompasing document.
> 
> I'm curious as to the position on this subject of the SIP 
> chairs.  Does
> the group advance a document that is not (and cannot be) supported by 
> the PSTN?
> 
> cheers,
> 
> -ken
> 
> 
> 
> 



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 11:29:55 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06701
	for ; Thu, 16 Mar 2000 11:29:55 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 623FF5310; Thu, 16 Mar 2000 11:27:25 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D4CF3530F; Thu, 16 Mar 2000 11:27:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 419275310
	for ; Thu, 16 Mar 2000 11:27:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 16 11:26:31 EST 2000
Received: from prima.time.saic.com ([205.153.241.31]) by dusty; Thu Mar 16 11:26:30 EST 2000
Received: from degas.time.saic.com (degas.time.saic.com [205.153.241.32])
	by prima.time.saic.com (8.9.3/8.8.5) with ESMTP id LAA06472;
	Thu, 16 Mar 2000 11:26:38 -0500 (EST)
Message-Id: <200003161626.LAA06472@prima.time.saic.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: "Rosen, Brian" 
Cc: jmpolk@cisco.com, sip@lists.research.bell-labs.com
Subject: Re: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt 
In-Reply-To: Your message of "Thu, 16 Mar 2000 11:16:30 EST."
             <4FBEA8857476D311A03300204840E1CF208AF8@whq-msgusr-02.fore.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 16 Mar 2000 11:23:05 -0500
From: Ken Carlberg 
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


> Perhaps I'm mistaken, but I believe the PSTN actually does
> implement MLPP, but it is only used by the government in
> emergency situations.

Unless the FCC changed things recently, MLPP in the US PSTN is a definite 
no-no.

> On your final thread, it should certainly be possible to define
> an extension to SIP that is not useful in the PSTN; extensions
> that are useful only within an enterprise for example should
> be acceptable, or in the home, as well as something like MLPP 
> which is useful within a government communications system.

Agreed with respect to something that may or may not be "useful".  But the
kicker that I'm curious about is whether the proposed specification is 
illegal (not allowed) when applied to the general public.

cheers,

-ken





From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 11:41:03 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11196
	for ; Thu, 16 Mar 2000 11:41:02 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 7FD4D530E; Thu, 16 Mar 2000 11:37:48 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id E1E585308; Thu, 16 Mar 2000 11:37:47 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id A1C495312
	for ; Thu, 16 Mar 2000 11:37:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 11:35:10 EST 2000
Received: from mailgate.fore.com ([169.144.68.6]) by dusty; Thu Mar 16 11:35:08 EST 2000
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12])
	by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA02999;
	Thu, 16 Mar 2000 11:35:05 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
	by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA15335;
	Thu, 16 Mar 2000 11:35:07 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 16 Mar 2000 11:30:47 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF208AF9@whq-msgusr-02.fore.com>
From: "Rosen, Brian" 
To: "'Ken Carlberg'" 
Cc: jmpolk@cisco.com, sip@lists.research.bell-labs.com
Subject: RE: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt 
Date: Thu, 16 Mar 2000 11:34:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

> > On your final thread, it should certainly be possible to define
> > an extension to SIP that is not useful in the PSTN; extensions
> > that are useful only within an enterprise for example should
> > be acceptable, or in the home, as well as something like MLPP 
> > which is useful within a government communications system.
> 
> Agreed with respect to something that may or may not be 
> "useful".  But the
> kicker that I'm curious about is whether the proposed 
> specification is 
> illegal (not allowed) when applied to the general public.

Suppose it was.  Is that a reason not to do it, if it's useful in
other circumstances?  Using encryption as defined in several IETF
protocols is illegal in many jurisdictions. 

It gets even more interesting if a service provider were to offer
to provide SIP proxy servers which would join several "enterprise"
domains where the extension was requested by the customer.

I would like to see this effort proceed.  It's a requirement in
certain circumstances, and it may be useful in others.  That it
might be unwanted, or illegal in other circumstances shouldn't
affect us.

Brian 



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 11:44:12 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12668
	for ; Thu, 16 Mar 2000 11:44:12 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 66F855313; Thu, 16 Mar 2000 11:37:49 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A318A5312; Thu, 16 Mar 2000 11:37:48 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 913565313
	for ; Thu, 16 Mar 2000 11:37:08 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 11:37:00 EST 2000
Received: from orinoco.cisco.com ([171.69.161.57]) by dusty; Thu Mar 16 11:36:59 EST 2000
Received: from rtbell-isdn4 (rtbell-isdn1.cisco.com [171.70.209.114])
	by orinoco.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA19029;
	Thu, 16 Mar 2000 10:36:17 -0600 (CST)
Message-Id: <4.2.0.58.20000316093230.0135b768@orinoco.cisco.com>
X-Sender: rtbell@orinoco.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 16 Mar 2000 09:36:29 -0700
To: Ken Carlberg , "Rosen, Brian" 
From: Bob Bell 
Subject: Re: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt 
Cc: jmpolk@cisco.com, sip@lists.research.bell-labs.com
In-Reply-To: <200003161626.LAA06472@prima.time.saic.com>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Ken -

One thing to consider is that in a non-PSTN network, such as the SIP 
network, the FCC rulings for the PSTN have no "legal" force. When the FCC 
made its ruling on MLPP in the PSTN, they were trying to prevent the 
commandeering of relatively scarce resources by a few "fat cats". In the IP 
world, it is possible to still retain communications with a lower QoS even 
though the higher QoS connection has been preempted. Anyway, that is just a 
thought.

Bob Bell


At 09:23  3/16/2000, Ken Carlberg wrote:

> > Perhaps I'm mistaken, but I believe the PSTN actually does
> > implement MLPP, but it is only used by the government in
> > emergency situations.
>
>Unless the FCC changed things recently, MLPP in the US PSTN is a definite
>no-no.
>
> > On your final thread, it should certainly be possible to define
> > an extension to SIP that is not useful in the PSTN; extensions
> > that are useful only within an enterprise for example should
> > be acceptable, or in the home, as well as something like MLPP
> > which is useful within a government communications system.
>
>Agreed with respect to something that may or may not be "useful".  But the
>kicker that I'm curious about is whether the proposed specification is
>illegal (not allowed) when applied to the general public.
>
>cheers,
>
>-ken
>
>
>

Bob Bell
Cisco Systems Inc.
801-294-3034(v)
801-294-3023(f)



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 12:03:58 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20610
	for ; Thu, 16 Mar 2000 12:03:57 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 5BF1F5308; Thu, 16 Mar 2000 12:01:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id C50A85311; Thu, 16 Mar 2000 12:01:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 495965308
	for ; Thu, 16 Mar 2000 12:01:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 11:59:30 EST 2000
Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Mar 16 11:59:29 EST 2000
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA27441;
	Thu, 16 Mar 2000 11:59:23 -0500 (EST)
Message-ID: <38D112E6.8FD78358@cs.columbia.edu>
Date: Thu, 16 Mar 2000 11:59:18 -0500
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: sip@lists.research.bell-labs.com, Robert.Sparks@wcom.com
Subject: Re: Comments on transfer draft (sparks-sip-cc-transfer-00)
References: <38C9406B.DD547641@cs.columbia.edu> <38D091C8.B596E724@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 

> 
> It would be really nice, however, to know ahead of time whether all
> parties supported transfer (and any other mechanisms to be defined). The
> Supported extension draft defines a way in which the UAC would indicate
> to the UAS that it knows the new mechanism, but that draft does not
> mandate that a UAS return a Supported header in the response to any
> method (only OPTIONS). We can add this, and say that if a UAS receives a
> request (with any method) with a Supported header, it should place a
> Supported header in the response and list those features it knows. This
> would allow a caller to know whether the called party supports transfer
> before trying it. Thoughts?

It might make sense to have both Allow and Supported in responses other
than OPTIONS. In this case, Allow seems the more appropriate solution,
given that it's a new method and that having two mechanisms to ask for
the same thing seems a bad design. Thus, suggesting that final responses
include Allow doesn't break anything (a UAC could have a simple logic
that did "if response didn't have Allow, send an OPTIONS just in case"),
but it does cut down on traffic. It's much nicer if the UAC can gray out
a Transfer button rather than pop up a failure note after the caller has
said "let me transfer you...".


> The document says TRANSFER can't have a body. Why not? I can think of
> some cool uses for this down the road. Why rule it out?

If nothing else, one can always use it for "if you get dropped, here's
the URL to click on to call me back...".

> 
> The draft says:
> > UA receiving a well-formed TRANSFER request SHOULD request approval
> >    from the user to proceed. In the absence of that request, or upon
> >    receiving approval from the user, the UA MUST submit an INVITE to
> >    the resource identified by the Transfer-To: header using the Call-ID
> >    from the TRANSFER request.
> 
> This thing about the Call-ID being copied from the TRANSFER seemed odd.
> Why is that? If you wanted to accomplish this, it seems better to have
> the URL in the Transfer-To header contain the Call-ID as a URL
> parameter. In other words, why not do:
> 
> Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays

Somehow, the recipient of the transfer request must know which call id
this belongs to. It can either be a new call (when TRANSFER is really
acting as a 'create call leg, please' request) or an existing call
(standard transfer). Why create a new call-id if it relates to an
existing call?

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 12:28:03 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29776
	for ; Thu, 16 Mar 2000 12:28:02 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id D184C5311; Thu, 16 Mar 2000 12:25:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 4FB235314; Thu, 16 Mar 2000 12:25:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 6ED865311
	for ; Thu, 16 Mar 2000 12:25:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 12:24:38 EST 2000
Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Thu Mar 16 12:24:38 EST 2000
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FRI00MEKZ0XTI@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Thu, 16 Mar 2000 17:24:33 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with ESMTP id <0FRI00601Z0W42@pmismtp02.wcomnet.com>;
 Thu, 16 Mar 2000 17:24:33 +0000 (GMT)
Received: from omzmta03.mcit.com ([166.37.214.9])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0FRI0058QZ0WIO@pmismtp02.wcomnet.com>; Thu,
 16 Mar 2000 17:24:32 +0000 (GMT)
Received: from wcom.com ([166.33.132.111])
 by omzmta03.mcit.com (InterMail v03.02.05 118 121 101)
 with ESMTP id <20000316172432.IOAA26687@wcom.com>; Thu,
 16 Mar 2000 17:24:32 +0000
Date: Thu, 16 Mar 2000 11:25:31 -0600
From: Alan Johnston 
Subject: Re: Comments on draft-ietf-sip-call-flows-00
To: Laurent-Walter Goix 
Cc: sip@lists.research.bell-labs.com
Message-id: <38D1190B.704530AD@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <33E324D95F44D311AA3E00204840075B550353@zhard00e.europe.nortel.com>
 <38D0FFD1.E121A1B@athena.polito.it>
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,

Thanks for the feedback - you are correct, these are errors and will be fixed. 
See my comments below.

Thanks again - all comments and corrections are greatly appreciated!

Alan Johnston
MCI WorldCom

Laurent-Walter Goix wrote:
> 
> Hi all
> 
> I have some comments about the draft-ietf-sip-call-flows-00.txt. Seems
> to be some errors in some call scenarios:
> 
> - page 110 (SIP->PSTN, bad PSTN number): as NGW1 receive from Proxy
> To:, doesn't it try an IAM (F5) with
> CdPN=+44-1234,NPI=E.164,NOA=International (or something like that)

Correct.  CdPN will be changed to the international number.

> 
> - page 138(Unsuccessful PSTN->SIP): what is said above the figure (NGW1
> sends a REL message back to A when receiving the 600 Busy Everywhere
> error from Proxy) is incompatible with both the figure and the call
> flows description: shouldn't the gateway send the REL message?

The call flows figure and the detailed messages are backwards, the text is
correct - the gateway originates the REL message.  This will be fixed.

> 
> - page 90(successful SIP->PSTN): how could user A send a PRACK message
> with the private number of B (F13) since Proxy nerver sended it this
> URL?
> Even if he could become it anyhow, might he send it a later INVITE (as
> he remembered this address in his "SIP address book") at this private
> number (How does the "globalization of the SIP URL" work is that case,
> if any?). Doesn't it raise the problem of a privacy or access violation?
> (even the PBX's  private numbers which don't correspond to any public
> number may be reachable directly)
> 

Correct - the Request-URI of the PRACK F13 must be the same as the initial
INVITE (sip:+1-918-555-3333@ss1.wcom.com;user=phone).  The URL containing the
private number is not known to the caller until the 200 OK with the Contact
header is received.  This will be fixed.  As for privacy, if the called party
does not want to share his/her private number with the caller, that Contact
header would not be present.

> Please correct me where I'm wrong.
> 
> Laurent-Walter Goix



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 20:00:03 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15848
	for ; Thu, 16 Mar 2000 20:00:03 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id E140F5300; Thu, 16 Mar 2000 19:57:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 49DDA5302; Thu, 16 Mar 2000 19:57:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 8ED565300
	for ; Thu, 16 Mar 2000 19:57:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 19:56:22 EST 2000
Received: from mail.pingtel.com ([216.91.1.131]) by dusty; Thu Mar 16 19:56:22 EST 2000
Received: from pingtel.com (cdhcp189.pingtel.com [10.1.1.189])
	by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id TAA15062;
	Thu, 16 Mar 2000 19:41:12 -0500
Message-ID: <38D182F6.E972233F@pingtel.com>
Date: Thu, 16 Mar 2000 19:57:26 -0500
From: "Daniel G. Petrie" 
Organization: Pingtel Corp. http://www.pingtel.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert.Sparks@wcom.com
Cc: Henning Schulzrinne ,
        Jonathan Rosenberg ,
        sip@lists.research.bell-labs.com
Subject: Re: Comments on transfer draft (sparks-sip-cc-transfer-00)
References: <38C9406B.DD547641@cs.columbia.edu> <38D091C8.B596E724@dynamicsoft.com> <38D112E6.8FD78358@cs.columbia.edu>
Content-Type: multipart/alternative;
 boundary="------------D99E79CC97F65CFD91723374"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


--------------D99E79CC97F65CFD91723374
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robert:
Thank you for putting the time into solving the problem
of confirmation of transfer completion. This has been on
our hit list as an awkward user experience.

Some comments below:


Henning Schulzrinne wrote:

> Jonathan Rosenberg wrote:
> >
>
> >
> > It would be really nice, however, to know ahead of time whether all
> > parties supported transfer (and any other mechanisms to be defined). The
> > Supported extension draft defines a way in which the UAC would indicate
> > to the UAS that it knows the new mechanism, but that draft does not
> > mandate that a UAS return a Supported header in the response to any
> > method (only OPTIONS). We can add this, and say that if a UAS receives a
> > request (with any method) with a Supported header, it should place a
> > Supported header in the response and list those features it knows. This
> > would allow a caller to know whether the called party supports transfer
> > before trying it. Thoughts?
>
> It might make sense to have both Allow and Supported in responses other
> than OPTIONS. In this case, Allow seems the more appropriate solution,
> given that it's a new method and that having two mechanisms to ask for
> the same thing seems a bad design. Thus, suggesting that final responses
> include Allow doesn't break anything (a UAC could have a simple logic
> that did "if response didn't have Allow, send an OPTIONS just in case"),
> but it does cut down on traffic. It's much nicer if the UAC can gray out
> a Transfer button rather than pop up a failure note after the caller has
> said "let me transfer you...".

I agree there is definitely a requirement to know ahead of time whether
the transferee supports transfer.  This seems like a reasonable approach.

>
>
> > The document says TRANSFER can't have a body. Why not? I can think of
> > some cool uses for this down the road. Why rule it out?
>
> If nothing else, one can always use it for "if you get dropped, here's
> the URL to click on to call me back...".
>
> >
> > The draft says:
> > > UA receiving a well-formed TRANSFER request SHOULD request approval
> > >    from the user to proceed. In the absence of that request, or upon
> > >    receiving approval from the user, the UA MUST submit an INVITE to
> > >    the resource identified by the Transfer-To: header using the Call-ID
> > >    from the TRANSFER request.
> >
> > This thing about the Call-ID being copied from the TRANSFER seemed odd.
> > Why is that? If you wanted to accomplish this, it seems better to have
> > the URL in the Transfer-To header contain the Call-ID as a URL
> > parameter. In other words, why not do:
> >
> > Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays
>
> Somehow, the recipient of the transfer request must know which call id
> this belongs to. It can either be a new call (when TRANSFER is really
> acting as a 'create call leg, please' request) or an existing call
> (standard transfer). Why create a new call-id if it relates to an
> existing call?

There are some definite advantages to requiring the transferee
use the same callId as the existing leg with the transferor.  Starting
with the call flow in 5.2.1 and extending it a bit (see below).

The  transfer target can know that the invite from the transferee is
part of an existing call and automatically (or with user approval)
answer it.  This is closer to the typicall experience in a PBX
base transfer in that ther transfer targets phone does not ring
after the consultation with the transferor.

The transferor (after completing the transfer and dropping both
legs to the transferee and transfer target), remembering that
she wanted to pass on some information relative to the
conversation the other two are having, can rejoin the call by
simply sending and invite to either the tranferee or the
transfer target.  Because the tranferor knows the call-id for
the call in progress the same call-id can be reused indicating
to the transferee (or transfer target) that the transfer would
like to join that particular call.  If the transferee supports
bridging of calls this can be a conference, if not the legs
can be toggled to/from hold.


     Transferor           Transferee         Transfer
          |                    |               Target
          |                    |                    |
Call-ID:1 | INVITE/180/200/ACK |                    |
          |<-------------------|                    |

Transferor and Transferee talk

Call-ID:1 | INVITE (hold)/200 OK/ACK                |
          |------------------->|                    |
Call-ID:1 | INVITE/180/200/ACK |                    |
          |---------------------------------------->|

Transferor and Transfer Target talk
If Tranferor supports bridging, it can conference
Transferee back in by taking it off hold

Call-ID:1 | INVITE/200/ACK     |                    |
          |<-------------------|                    |

All three talk.
Transferor gets out of the call.

Call-ID:1 | INVITE (hold)/200 OK/ACK                |
          |---------------------------------------->|
Call-ID:1 | TRANSFER           |                    |
          |------------------->|                    |
          | 100 Trying         |                    |
          |<-------------------|                    |
Call-ID:1 |                    |  INVITE/200 OK/ACK |
          |                    |------------------->|

Transfer target automatically (or interactively)
answers the INVITE from transferee as the call ID
matches the existing call with transferee.

          | 200 OK             |                    |
          |<-------------------|                    |
Call-ID:1 | BYE/200 OK         |                    |
          |------------------->|                    |
Call-ID:1 | BYE/200 OK         |                    |
          |---------------------------------------->|
Call-ID:1 |                    |         BYE/200 OK |
          |                    |<-------------------|

Transferor remembers discussion point for
conversation between Transferee and Transfer
target after completing the transfer and byes.

Call-ID:1 | INVITE/180/200/ACK |                    |
          |<-------------------|                    |

Transferee bridges in Transferee (if not capable
of bridging puts transfer target on hold).  Etc. ...



--------------D99E79CC97F65CFD91723374
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Robert:

Thank you for putting the time into solving the problem

of confirmation of transfer completion. This has been on

our hit list as an awkward user experience.

Some comments below:

 

Henning Schulzrinne wrote:

Jonathan Rosenberg wrote:

>

>

> It would be really nice, however, to know ahead of time whether all

> parties supported transfer (and any other mechanisms to be defined).
The

> Supported extension draft defines a way in which the UAC would indicate

> to the UAS that it knows the new mechanism, but that draft does not

> mandate that a UAS return a Supported header in the response to any

> method (only OPTIONS). We can add this, and say that if a UAS receives
a

> request (with any method) with a Supported header, it should place
a

> Supported header in the response and list those features it knows.
This

> would allow a caller to know whether the called party supports transfer

> before trying it. Thoughts?

It might make sense to have both Allow and Supported in responses other

than OPTIONS. In this case, Allow seems the more appropriate solution,

given that it's a new method and that having two mechanisms to ask
for

the same thing seems a bad design. Thus, suggesting that final responses

include Allow doesn't break anything (a UAC could have a simple logic

that did "if response didn't have Allow, send an OPTIONS just in case"),

but it does cut down on traffic. It's much nicer if the UAC can gray
out

a Transfer button rather than pop up a failure note after the caller
has

said "let me transfer you...".

I agree there is definitely a requirement to know ahead of time whether

the transferee supports transfer.  This seems like a reasonable
approach.

 

> The document says TRANSFER can't have a body. Why not? I can think
of

> some cool uses for this down the road. Why rule it out?

If nothing else, one can always use it for "if you get dropped, here's

the URL to click on to call me back...".

>

> The draft says:

> > UA receiving a well-formed TRANSFER request SHOULD request approval

> >    from the user to proceed. In the absence of that
request, or upon

> >    receiving approval from the user, the UA MUST
submit an INVITE to

> >    the resource identified by the Transfer-To: header
using the Call-ID

> >    from the TRANSFER request.

>

> This thing about the Call-ID being copied from the TRANSFER seemed
odd.

> Why is that? If you wanted to accomplish this, it seems better to
have

> the URL in the Transfer-To header contain the Call-ID as a URL

> parameter. In other words, why not do:

>

> Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays

Somehow, the recipient of the transfer request must know which call
id

this belongs to. It can either be a new call (when TRANSFER is really

acting as a 'create call leg, please' request) or an existing call

(standard transfer). Why create a new call-id if it relates to an

existing call?

There are some definite advantages to requiring the transferee

use the same callId as the existing leg with the transferor. 
Starting

with the call flow in 5.2.1 and extending it a bit (see below).

The  transfer target can know that the invite from the transferee
is

part of an existing call and automatically (or with user approval)

answer it.  This is closer to the typicall experience in a PBX

base transfer in that ther transfer targets phone does not ring

after the consultation with the transferor.

The transferor (after completing the transfer and dropping both

legs to the transferee and transfer target), remembering that

she wanted to pass on some information relative to the

conversation the other two are having, can rejoin the call by

simply sending and invite to either the tranferee or the

transfer target.  Because the tranferor knows the call-id for

the call in progress the same call-id can be reused indicating

to the transferee (or transfer target) that the transfer would

like to join that particular call.  If the transferee supports

bridging of calls this can be a conference, if not the legs

can be toggled to/from hold.

 

     Transferor          
Transferee         Transfer

          |                   
|              
Target

          |                   
|                   
|

Call-ID:1 | INVITE/180/200/ACK |                   
|

          |<-------------------|                   
|

Transferor and Transferee talk

Call-ID:1 | INVITE (hold)/200 OK/ACK               
|

          |------------------->|                   
|

Call-ID:1 | INVITE/180/200/ACK |                   
|

          |---------------------------------------->|

Transferor and Transfer Target talk

If Tranferor supports bridging, it can conference

Transferee back in by taking it off hold

Call-ID:1 | INVITE/200/ACK     |                   
|

          |<-------------------|                   
|

All three talk.

Transferor gets out of the call.

Call-ID:1 | INVITE (hold)/200 OK/ACK               
|

          |---------------------------------------->|

Call-ID:1 | TRANSFER          
|                   
|

          |------------------->|                   
|

          | 100 Trying        
|                   
|

          |<-------------------|                   
|

Call-ID:1 |                   
|  INVITE/200 OK/ACK |

          |                   
|------------------->|

Transfer target automatically (or interactively)

answers the INVITE from transferee as the call ID

matches the existing call with transferee.

          | 200 OK            
|                   
|

          |<-------------------|                   
|

Call-ID:1 | BYE/200 OK        
|                   
|

          |------------------->|                   
|

Call-ID:1 | BYE/200 OK        
|                   
|

          |---------------------------------------->|

Call-ID:1 |                   
|         BYE/200 OK |

          |                   
|<-------------------|

Transferor remembers discussion point for

conversation between Transferee and Transfer

target after completing the transfer and byes.

Call-ID:1 | INVITE/180/200/ACK |                   
|

          |<-------------------|                   
|

Transferee bridges in Transferee (if not capable

of bridging puts transfer target on hold).  Etc. ...

 

 

--------------D99E79CC97F65CFD91723374--




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 21:33:49 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22476
	for ; Thu, 16 Mar 2000 21:33:48 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 1B32152FA; Thu, 16 Mar 2000 21:31:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9089F5306; Thu, 16 Mar 2000 21:31:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id D766C52FA
	for ; Thu, 16 Mar 2000 21:31:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 21:30:05 EST 2000
Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Thu Mar 16 21:30:05 EST 2000
Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178])
	by repulse.cnchost.com
	id VAA05138; Thu, 16 Mar 2000 21:29:59 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38D198A6.14D3742C@vovida.com>
Date: Thu, 16 Mar 2000 18:29:58 -0800
From: Sunitha Kumar 
Organization: Vovida Networks
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: SIPbell-labs 
Subject: BYE and record route
Content-Type: multipart/alternative;
 boundary="------------A8EEE661B04792F72052C57E"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


--------------A8EEE661B04792F72052C57E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It is given that the record route in 200 OK is copied into  the Route
headers for subsequent requests from the caller.  My question was, if we
needed to make the BYE from the *callee*  traverse the same set of
proxies, then  should this be rememberd from the INVITE request obtained
from the caller, or does the via field help in that.

Thanks!

--
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374



--------------A8EEE661B04792F72052C57E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



It is given that the record route in 200 OK is copied into  the Route
headers for subsequent requests from the caller.  My question was,
if we needed to make the BYE from the *callee*  traverse the same
set of proxies, then  should this be rememberd from the INVITE request
obtained from the caller, or does the via field help in that.

Thanks!

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374

 

--------------A8EEE661B04792F72052C57E--




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 23:27:54 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09616
	for ; Thu, 16 Mar 2000 23:27:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id C13915306; Thu, 16 Mar 2000 23:25:19 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 4219E530D; Thu, 16 Mar 2000 23:25:19 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id ADF935306
	for ; Thu, 16 Mar 2000 23:25:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 23:24:40 EST 2000
Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Mar 16 23:24:40 EST 2000
Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: 1Cust137.tnt1.long-branch.nj.da.uu.net [63.25.225.137])
	id QQigvx19145;
	Fri, 17 Mar 2000 04:24:37 GMT
Message-ID: <38D1B3F4.3C8CCA99@dynamicsoft.com>
Date: Thu, 16 Mar 2000 23:26:28 -0500
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sunitha Kumar 
Cc: SIPbell-labs 
Subject: Re: BYE and record route
References: <38D198A6.14D3742C@vovida.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

It certainly should, and not only for BYE requests. This is discussed in
http://www.cs.columbia.edu/~hgs/sip/notes.html (see the note on
Record-Route towards the end of the document) and in
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-2543bis-00.pdf
(section 6.3.33).

---
Igor Slepchin
 

Sunitha Kumar wrote:
> 
> It is given that the record route in 200 OK is copied into  the Route
> headers for subsequent requests from the caller.  My question was, if
> we needed to make the BYE from the *callee*  traverse the same set of
> proxies, then  should this be rememberd from the INVITE request
> obtained from the caller, or does the via field help in that.
> 
> Thanks!
> 
> --
> Sunitha Kumar
> Software Engineer
> Vovida Networks
> (408) 957 - 6374
> 
>



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 16 23:34:04 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12434
	for ; Thu, 16 Mar 2000 23:34:04 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id C7000530F; Thu, 16 Mar 2000 23:31:35 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 3A60F530D; Thu, 16 Mar 2000 23:31:35 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id C69EE530F
	for ; Thu, 16 Mar 2000 23:31:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 23:29:31 EST 2000
Received: from diablo.cisco.com ([171.68.224.210]) by dusty; Thu Mar 16 23:29:30 EST 2000
Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id UAA12763; Thu, 16 Mar 2000 20:28:54 -0800 (PST)
Message-Id: <4.1.20000316221051.00af1150@diablo.cisco.com>
X-Sender: jmpolk@diablo.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 16 Mar 2000 22:27:35 -0600
To: Ken Carlberg 
From: "James M. Polk" 
Subject: Re: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt 
Cc: sip@lists.research.bell-labs.com
In-Reply-To: <200003161604.LAA06420@prima.time.saic.com>
References: 
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_4069539==_.ALT"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

--=====================_4069539==_.ALT
Content-Type: text/plain; charset="us-ascii"

Ken

Thanks for the comments.

To address your concern, I purposely included the following at the end of page
3 of the I-D:
"Further, this document recommends the ability to make the Header-Field
"Priority:" mandatory within an Administrator's Domain if they choose, for all
SIP based call signaling devices. "

Key phrase here is "...if they choose..."

and

Section 7 (page 7) states as the 4th bullet: 
    * MUST allow Administrator to make it mandatory for any SIP receiving
device
    to be MLPP-enabled (goal to have any non-MLPP device not able to engage in
    any call session - in a MLPP environment, this capability should be
    required of all devices by that Domain's Administrator) 
Here is the stated purpose and control a Domain Administrator has within that
Domain only. Not the PSTN. I guess I need to make that clearer in the next
version. I'll do this with no hesitation. 

I think I also address what you state:
"would prefer a document that included both preemptive and non-preemptive
values"

in two ways:

#1      By making this Preemptive Capability only "enabled" within a Domain if
the DA chooses to mandate this feature, if they don't (like the PSTN), there
isn't any preemption; and

#2      By stating that the default Header-Field "Priority:" value be "Routine"
-- thereby meaning most traffic even within a MLPP enabled SIP network will not
Preempt any other voice sessions -- as they would be of the same Precedence
Level, preventing Preemption.

Though again, I can make this clearer with the next I-D version.

At 11:00 AM 3/16/2000 -0500, Ken Carlberg wrote:
>
>> Like so many others -- I'm letting you know of a new Draft 
>> (draft-polk-sip-mlpp-mapping-00.txt) that addresses 'Multi-Level 
>> Precedence and Preemption' in SIP environments. Specifically it provides 
>> the background of existing Voice Networks that have specific requirements 
>> for differentiating Classes of Voice traffic, not just Voice from all other 
>> types of traffic. This I-D also recommends the ability to mandate the 
>> Header-Field 'Priority:' during session set-up within a domain (analagous 
>> to how the existing MLPP  networks function today), but with the obvious 
>> advantages of IP (vs. TDM). I know that should get some attention by itself.
>
>Nice piece of work, however I have some concerns.  First, some background 
>info.
>
>Within the U.S., MLPP (ANSI-T1.619A) is only available on some military 
>systems like Autovon.  It is _illegal_ to use it (i believe by mandate of 
>FCC) in the U.S. PSTN because it involves *preemption* of calls.  I don't 
>believe there is another country that allows its PSTN to preempt existing 
>calls, though I would appreciate being corrected on this.  So I have some
>concern about mandating SIP receivers to recognize MLPP if it can only
>be used within closed-loop/non-public systems.  
>
>On the other hand, the SS7 system of Sprint, MCI, and AT&T support 
>ANSI-T1.631-1993 -- High Probability of Completion (HPC), in which 
>emergency calls are marked accordingly and are queued to improve the
>*probability* that their call will be completed.  I.e., no preemption
>is generated by the emergency call.  
>
>Part of the reason I bring this up is that if one is going to specify a 
>more definitive description of priority for SIP, as well as the action to 
>be taken, then I would prefer a document that included both preemptive and 
>non-preemptive values.  I agree there is a need/marketplace for SIP-MLPP, 
>but I'd prefer to see a more encompasing document.
>
>I'm curious as to the position on this subject of the SIP chairs.  Does
>the group advance a document that is not (and cannot be) supported by 
>the PSTN?
>
>cheers,
>
>-ken
>
>
>
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com
--=====================_4069539==_.ALT
Content-Type: text/html; charset="us-ascii"


Ken



Thanks for the comments.



To address your concern, I purposely included the following at the end of
page 3 of the I-D:





"Further, this document recommends the ability to make the
Header-Field "Priority:" mandatory within an Administrator's
Domain if they choose, for all SIP based call signaling devices.
"





Key phrase here is "...if they choose..."



and



Section 7 (page 7) states as the 4th bullet:

    

  • MUST allow Administrator to make it mandatory for any SIP receiving
device to be MLPP-enabled (goal to have any non-MLPP device not able to
engage in any call session - in a MLPP environment, this capability
should be required of all devices by that Domain's Administrator)

Here is the stated purpose and control a Domain Administrator has
within that Domain only. Not the PSTN. I guess I need to make that
clearer in the next version. I'll do this with no hesitation. 



I think I also address what you state:





"would prefer a document that included both preemptive and
non-preemptive values"





in two ways:



#1      By making this
Preemptive Capability only "enabled" within a Domain if the DA
chooses to mandate this feature, if they don't (like the PSTN), there
isn't any preemption; and



#2      By stating that the
default Header-Field "Priority:" value be "Routine"
-- thereby meaning most traffic even within a MLPP enabled SIP network
will not Preempt any other voice sessions -- as they would be of the same
Precedence Level, preventing Preemption.



Though again, I can make this clearer with the next I-D version.



At 11:00 AM 3/16/2000 -0500, Ken Carlberg wrote:

>

>> Like so many others -- I'm letting you know of a new Draft 


>> (draft-polk-sip-mlpp-mapping-00.txt) that addresses 'Multi-Level


>> Precedence and Preemption' in SIP environments. Specifically it
provides 

>> the background of existing Voice Networks that have specific
requirements 

>> for differentiating Classes of Voice traffic, not just Voice
from all other 

>> types of traffic. This I-D also recommends the ability to
mandate the 

>> Header-Field 'Priority:' during session set-up within a domain
(analagous 

>> to how the existing MLPP  networks function today), but
with the obvious 

>> advantages of IP (vs. TDM). I know that should get some
attention by itself.

>

>Nice piece of work, however I have some concerns.  First, some
background 

>info.

>

>Within the U.S., MLPP (ANSI-T1.619A) is only available on some
military 

>systems like Autovon.  It is _illegal_ to use it (i believe by
mandate of 

>FCC) in the U.S. PSTN because it involves *preemption* of
calls.  I don't 

>believe there is another country that allows its PSTN to preempt
existing 

>calls, though I would appreciate being corrected on this.  So I
have some

>concern about mandating SIP receivers to recognize MLPP if it can
only

>be used within closed-loop/non-public systems.  

>

>On the other hand, the SS7 system of Sprint, MCI, and AT&T
support 

>ANSI-T1.631-1993 -- High Probability of Completion (HPC), in which


>emergency calls are marked accordingly and are queued to improve
the

>*probability* that their call will be completed.  I.e., no
preemption

>is generated by the emergency call.  

>

>Part of the reason I bring this up is that if one is going to specify
a 

>more definitive description of priority for SIP, as well as the
action to 

>be taken, then I would prefer a document that included both
preemptive and 

>non-preemptive values.  I agree there is a need/marketplace for
SIP-MLPP, 

>but I'd prefer to see a more encompasing document.

>

>I'm curious as to the position on this subject of the SIP
chairs.  Does

>the group advance a document that is not (and cannot be) supported by


>the PSTN?

>

>cheers,

>

>-ken

>

>

>

>






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

"At the end of the day... the most committed win!"





James M. Polk

Sr. Product Manager, Multiservice Architecture and Standards

Enterprise Voice Business Unit

Cisco Systems

Dallas, Texas

w) 972.813.5208

f)  972.813.5280

www.cisco.com

--=====================_4069539==_.ALT--




From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 00:46:03 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11567
	for ; Fri, 17 Mar 2000 00:46:02 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 436765302; Fri, 17 Mar 2000 00:43:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id DFFC2530D; Fri, 17 Mar 2000 00:43:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id A871E5302
	for ; Fri, 17 Mar 2000 00:43:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 17 00:41:24 EST 2000
Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Mar 17 00:41:23 EST 2000
Received: from dynamicsoft.com (1Cust237.tnt1.freehold.nj.da.uu.net [63.17.113.237])
	by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA15984;
	Fri, 17 Mar 2000 00:41:19 -0500 (EST)
Message-ID: <38D1C706.20D072A4@dynamicsoft.com>
Date: Fri, 17 Mar 2000 00:47:50 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Slepchin 
Cc: Sunitha Kumar ,
        SIPbell-labs 
Subject: Re: BYE and record route
References: <38D198A6.14D3742C@vovida.com> <38D1B3F4.3C8CCA99@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Let me make a general comment here on mailing list usage.

The SIP mailing list is an excellent place to address questions
regarding the specification. However, the purpose of the list is to work
on our deliverables as a working group. Time spent by the group
answering questions that have been discussed before is less time the
group can spend making forward progress on our documents. So, to try and
keep focused, I would encourage people to do the following. Before
asking your question to the list, please check the FAQ, the archives,
and the rfc2543bis draft to see if your question is answered there. If
not, then of course go ahead and ask on the list.

Thanks,
Jonathan R.

Igor Slepchin wrote:
> 
> It certainly should, and not only for BYE requests. This is discussed in
> http://www.cs.columbia.edu/~hgs/sip/notes.html (see the note on
> Record-Route towards the end of the document) and in
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-2543bis-00.pdf
> (section 6.3.33).
> 
> ---
> Igor Slepchin
> 
> 
> Sunitha Kumar wrote:
> >
> > It is given that the record route in 200 OK is copied into  the Route
> > headers for subsequent requests from the caller.  My question was, if
> > we needed to make the BYE from the *callee*  traverse the same set of
> > proxies, then  should this be rememberd from the INVITE request
> > obtained from the caller, or does the via field help in that.
> >
> > Thanks!
> >
> > --
> > Sunitha Kumar
> > Software Engineer
> > Vovida Networks
> > (408) 957 - 6374
> >
> >

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 01:08:43 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21693
	for ; Fri, 17 Mar 2000 01:08:42 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id D4928530D; Fri, 17 Mar 2000 01:05:38 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 3A5EE5311; Fri, 17 Mar 2000 01:05:38 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id E208A530D
	for ; Fri, 17 Mar 2000 01:05:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 17 01:03:34 EST 2000
Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Mar 17 01:03:33 EST 2000
Received: from dynamicsoft.com (1Cust237.tnt1.freehold.nj.da.uu.net [63.17.113.237])
	by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16010;
	Fri, 17 Mar 2000 01:03:23 -0500 (EST)
Message-ID: <38D1CC33.43866C10@dynamicsoft.com>
Date: Fri, 17 Mar 2000 01:09:55 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert.Sparks@wcom.com
Cc: "'Henning Schulzrinne'" ,
        sip@lists.research.bell-labs.com
Subject: Re: Comments on transfer draft (sparks-sip-cc-transfer-00)
References: <001301bf8f54$1ecc6600$999923a6@mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Robert Sparks wrote:
> 
> > Why? I really liked the idea of knowing that this call was
> > the result of
> > a transfer, and knowing who the transferor was. A UA can always ignore
> > this information, and then get the basic service you have today.
> 
> I really like the idea too. Perhaps as part of the work right now we
> can capture knowing that the call was the result of a transfer (by adding
> an informational header to the invite - something that doesn't change
> the invite semantics), but my preference is to wait for direction from
> the SIP security task folks before addressing telling the transfer target
> who the transferor was.

There isn't going to be any magic poof that causes a solution to be
generated. I think its the job of the author of the extension to propose
some security mechanism so that there can be a starting point for
discussion.

> 
> > The document says TRANSFER can't have a body. Why not? I can think of
> > some cool uses for this down the road. Why rule it out?
> 
> For consistency of implementation? (btw - One of those cool uses could be
> providing the identity of the transferor.) The presence of a body
> would likely affect the semantics of the operation (if it were honored,
> hence the consistency comment) through side-effects if not directly,
> so would it not make sense for the addition of a body to the base
> method be an actual extention?

The presence of a body should not, in any way, alter the basic semantics
of the request. Treatment of a body in TRANSFER is no different than
bodies in any other request. If the UAS doesn't know what to do with it,
it sends a 415. If it does know what to do with  it, it gets processed.


> > This thing about the Call-ID being copied from the TRANSFER
> > seemed odd.
> > Why is that? If you wanted to accomplish this, it seems better to have
> > the URL in the Transfer-To header contain the Call-ID as a URL
> > parameter. In other words, why not do:
> >
> > Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays
> 
> Interesing thought! Can we explore your thinking more here?
> Using this, the TRANSFER would look like
> 
> TRANSFER sip:transferee@transfereehost
> Transfer-To: sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
> Call-ID: abc@eeOrorhost
> 
> Are you suggesting the subsequent invite look like this?
> 
> INVITE sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
> Call-ID: def@eehost

No, like this:

INVITE sip:transfer-target@targethost
Call-ID: abc@ee0rorhost

This way, the tranferror could ask the transferred party to add other
headers or even body elements. 


> On reflection, I specified this copy because it resulted in
> a call-leg tuple that looked the same as it would have after
> a sip-cc-01 blind transfer. The motivation that draft had for
> this behavior may not apply here. Is there any value in keeping
> the Call-ID information accross this function (thinking of it
> as PLEASEINVITE instead of TRANSFER)?

Perhaps. By allowing the Call-ID to be used to be placed in the URL in
the Transfer-To header, the transferror can make the call-id the same,
different, or unspecified. This seems to result in maximum flexibility.


Later, Henning Schulzrinne writes:
> > 
> > It would be really nice, however, to know ahead of time whether all
> > parties supported transfer (and any other mechanisms to be defined). The
> > Supported extension draft defines a way in which the UAC would indicate
> > to the UAS that it knows the new mechanism, but that draft does not
> > mandate that a UAS return a Supported header in the response to any
> > method (only OPTIONS). We can add this, and say that if a UAS receives a
> > request (with any method) with a Supported header, it should place a
> > Supported header in the response and list those features it knows. This
> > would allow a caller to know whether the called party supports transfer
> > before trying it. Thoughts?
> 
> It might make sense to have both Allow and Supported in responses other
> than OPTIONS. In this case, Allow seems the more appropriate solution,
> given that it's a new method and that having two mechanisms to ask for
> the same thing seems a bad design.

You're right, its Allow here, not Supported.

> Thus, suggesting that final responses
> include Allow doesn't break anything (a UAC could have a simple logic
> that did "if response didn't have Allow, send an OPTIONS just in case"),
> but it does cut down on traffic. It's much nicer if the UAC can gray out
> a Transfer button rather than pop up a failure note after the caller has
> said "let me transfer you...".

Definitely.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 01:49:52 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12846
	for ; Fri, 17 Mar 2000 01:49:51 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id DB3A05312; Fri, 17 Mar 2000 01:47:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 601555314; Fri, 17 Mar 2000 01:47:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 578365312
	for ; Fri, 17 Mar 2000 01:47:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 17 01:45:55 EST 2000
Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Fri Mar 17 01:45:54 EST 2000
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id HAA05031
	for ; Fri, 17 Mar 2000 07:45:52 +0100 (MET)
From: Kimmo.Rantanen@lmf.ericsson.se
Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se [131.160.1.6])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA15294
	for ; Fri, 17 Mar 2000 08:45:49 +0200 (EET)
Received: from localhost (root@localhost)
	by greymse1.lmf.ericsson.se (8.8.6 (PHNE_17135)/8.8.6) with SMTP id IAA09653
	for sip@lists.research.bell-labs.com; Fri, 17 Mar 2000 08:45:48 +0200 (EET)
X-OpenMail-Hops: 1
Date: Fri, 17 Mar 2000 08:45:36 +0200
Message-Id: 
In-Reply-To: <38D093F2.F0495005@mail.lgcit.com>
Subject: Question on RTP
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Content-Type: text/plain; charset=ISO-8859-1; name="Question"
Content-Disposition: inline; filename="Question"
Content-Transfer-Encoding: 8bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 8bit

Hi,

I like to add one more question:

Is it absolutely necessary that both direction use the same type of
codec ?

/Kimmo



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 02:20:02 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01041
	for ; Fri, 17 Mar 2000 02:20:00 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id F21FB52BB; Fri, 17 Mar 2000 02:17:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5967C52C8; Fri, 17 Mar 2000 02:17:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 1DC9C52BB
	for ; Fri, 17 Mar 2000 02:17:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 17 02:15:21 EST 2000
Received: from dgesmtp01.wcom.com ([199.249.16.16]) by dusty; Fri Mar 17 02:15:20 EST 2000
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FRK00ECB1H9LS@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Fri, 17 Mar 2000 07:15:18 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with ESMTP id <0FRK002011H9E4@pmismtp01.wcomnet.com>;
 Fri, 17 Mar 2000 07:15:09 +0000 (GMT)
Received: from omzmta02.mcit.com ([166.37.214.8])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FRK001871H86P@pmismtp01.wcomnet.com>; Fri,
 17 Mar 2000 07:15:09 +0000 (GMT)
Received: from dwillispc8 ([166.44.162.170])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with SMTP id <20000317071507.CCUR7635@[166.44.162.170]>; Fri,
 17 Mar 2000 07:15:07 +0000
Date: Fri, 17 Mar 2000 01:14:22 -0600
From: Dean Willis 
Subject: Draft agenda SIP WG published
To: IETF SIP 
Cc: Jonathan Rosenberg ,
        Joerg Ott 
Message-id: <002501bf8fe0$6b86b5e0$aaa22ca6@wcomnet.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: multipart/mixed; boundary="Boundary_(ID_OetUG6Bku/KPdVh++gR5hg)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

This is a multi-part message in MIME format.

--Boundary_(ID_OetUG6Bku/KPdVh++gR5hg)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


The draft agenda for Adelaide is at

http://www.softarmor.com/sipwg/meets/IETF47/agenda.html

with HTML attached for those of you who are web-deprived.

If you see any glaring errors, please let Jonathan, Joerg, and I know ASAP.
It's due at noon later today. I hope most of my errors were caught in my
requests for feedback on the agenda request list.

--
Dean Willis
SIP WG cochair

--Boundary_(ID_OetUG6Bku/KPdVh++gR5hg)
Content-type: text/html; CHARSET=US-ASCII; name="Agenda, IETF 47, SIP WG.htm"
Content-disposition: attachment; filename="Agenda, IETF 47, SIP WG.htm"
Content-Transfer-Encoding: quoted-printable



Agenda, IETF 47, SIP WG




Agenda, IETF 47 SIP WG Session (Draft)


Proposed draft pending chair review.





Monday, March 27, 2000
0930 - 1130

<=
/TR>
  <=
/TR>
  <=
/TR>
  <=
/TR>
  <=
/TR>
  <=
/TR>
  

  
  

    Presenter
    Title
    Time
    Contact

  

    Chairs
    Agenda Bashing
    0930
0:5		
    dean.willis@wcom.com

  

    Chairs
    Milestone Status
      

        
        

          Goal/
Status		
          
          Task

        

          Dec 99
Feb 00		
            
          INFO Method extension submitted to IESG 

        

          Feb 00
Soon		
            
          Early session establishment extension submitted to =
IESG

        

          Mar 00
Soon		
            
          Caller preferences specification submitted to =
IESG

        

          May 00
Open		
            
          Call control specification submitted to IESG

        

          Jul 00
Open		
            
          Draft standard version of SIP submitted to IESG

        

          Jul 00
open		
            
          SIP MIB submitted to IESG

    0935
0:5		
    dean.willis@wcom.com

  

    Chairs
    Charter Discussion
Consider as WG =
items, set=20
      milestones for:
      
    
        
  • SIP Server Features Negotiation=20
        
  • Call Flows (Informational)=20
        
  • SIP Session Timer=20
        
  • Reliability for Provisional Messages=20
        
  • SIP-Telephony=20
        
  • Convergence with the PacketCable DCS Spec (DCS=20
        Team)=20
        
  • Security=20
        
  • Single Line Extension  

    0945
0:15		
    dean.willis@wcom.com

  

    Jonathan Rosenberg
    WG status and current list =
topics
draft-nair-sip-dhcp-00.txt
other=20
      stuff from list		
    1000
0:15		
    jdrosen@dynamicsoft.com

    Jonathan Rosenberg 
    draft-ietf-sip-callerprefs-01.txt
WG=20
      charter item, review changes, no open issues, plan to last call =
following=20
      session timer and reliable provisional, schedule critical		
    1015
0:10		
    jdrosen@dynamicsoft.com

    Steve Donovan
    darft-ietf-sip-info-method-01.txt
WG=20
      charter item, IESG, last call scheduled 3/18		
    1025
0:05		
    Steven.R.Donovan@wcom.com

  

    Steve Donovan
    =
draft-ietf-sip-183-00.txt=20
      (old draft)
WG charter item, review status, issues
Schecdule =

    critical		
    1030
0:05		
    Steven.R.Donovan@wcom.com

  

    Jonathan Rosenberg
    draft-ietf-sip-serverfeatures-02.txt
Proposed=20
      WG charter item, ready for IESG		
    1035
0:10		
    jdrosen@dynamicsoft.com

    Jonathan Rosenberg
    draft-ietf-sip-100rel-00.txt
Proposed=20
      WG charter item, review open issues, move quickly		
    1045
0:10		
    jdrosen@dynamicsoft.com

    Jonathan Rosenberg
    draft-rosenberg-sip-guidelines-00.txt
Question:=20
      Interest in BCP track WG effort?		
    1055
0:10		
    jdrosen@dynamicsoft.com

    Jonathan Rosenberg
    draft-rosenberg-sip-3pcc-00.txt
three-party=20
      call control, Question: WG task?		
    1105
0:10		
    jdrosen@dynamicsoft.com

    Dave Walker
    =
draft-ietf-sip-mib-00.txt
WG=20
      Charter item		
    1115
0:15		
    drwalker@ss8networks.com

  

    Chairs
    Wrap
    1130
    


 


Tuesday, March 28, 2000
1300-1515

<=
/TR>
  <=
/TR>
  <=
/TR>
  <=
/TR>
  =

  

  
  

    Presenter
    Title
    Time
    Contact

  

    Chairs
    Intro and Agenda
    1300
0:5		
    dean.willis@wcom.com

  

    Robert Sparks
    draft-campbell-sip-cc-framework-00.txt
WG=20
      Charter Item, Status Critical		
    1305
0:15		
    robert.sparks@wcom.com
  

    Robert Sparks
    draft-sparks-sip-cc-transfer-00.txt
WG=20
      Charter Item, Status Critical		
    1320
0:10		
    robert.sparks@wcom.com
  

    TBD
    SIP-T Status Report
    1335
0:5		
    TBD

  

    Gonzalo Camarillo
    draft-camarillo-sip-isup-bcp-00.txt
Proposed=20
      WG charter item?		
    1340
0:10		
    gonzalo.camarillo@ercicss=
on.com

  

    Steve Donovan
    draft-ietf-sip-session-timer-01.txt
Proposed=20
      WG charter item, review changes, issues, move quick		
    1350
0:10		
    Steven.R.Donovan@wcom.com

  

    James Polk
    draft-polk-sip-mlpp-mapping-00.txt
    1400
0:15		
    jmpolk@cisco.com 

  

    Adam Roach
    draft-roach-sip-subscribe-notify-00.txt
    1415
0:10		
    adam.roach@ericsson.com

    Henry Sinnreich 
    draft-sinnreich-sip-qos-osp-01.txt
    1425
0:15		
    henry.sinnreich@wcom.com

  

    Jonathan Rosenberg
    draft-lennox-sip-reg-payload-00.txt
    1440
0:15		
    jdrosen@dynamicsoft.com

    Jonathan Rosenberg
    draft-rosenberg-sip-firewalls-00.txt
Question;=20
      Interest in info track WG effort?		
    1455
0:14		
    jdrosen@dynamicsoft.com

    Jonathan Rosenberg
    dr=
aft-rs-trip-gw-00.txt
intro=20
      of related draft from IPTEL		
    1509
0:1		
    jdrosen@dynamicsoft.com

    Robert Sparks
    draft-campbell-sip-service-control-00.txt
    1510
0:5		
    robert.sparks@wcom.co

    Jeff Mark 
    draft-mark-sip-dmcs-00.txt
    1515
0:10		
    mailto:[Jeff.Mark@Dialogic.com

  

    Shinichi Baba 
    draft-itsumo-sip-mobility-req-00.txt
    1525
0:5		
    sbaba@tari.toshiba.com =


  

    Chairs
    Wrap
    1530
    





Revised March=20
17, 2000 18:57=20
GMT


--Boundary_(ID_OetUG6Bku/KPdVh++gR5hg)--



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 03:49:58 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08492
	for ; Fri, 17 Mar 2000 03:49:58 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 2091552B6; Fri, 17 Mar 2000 03:47:21 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 90F6652E0; Fri, 17 Mar 2000 03:47:20 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 475C352B6
	for ; Fri, 17 Mar 2000 03:47:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 17 03:45:39 EST 2000
Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by dusty; Fri Mar 17 03:45:38 EST 2000
Received: from csperkins.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP 
          id ; Fri, 17 Mar 2000 08:45:06 +0000
Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) 
          by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id IAA05102;
          Fri, 17 Mar 2000 08:23:36 GMT
Message-Id: <200003170823.IAA05102@csperkins.demon.co.uk>
To: Kimmo.Rantanen@lmf.ericsson.se
Cc: sip@lists.research.bell-labs.com
Subject: Re: Question on RTP
In-Reply-To: Message from Kimmo.Rantanen@lmf.ericsson.se of "Fri, 17 Mar 2000 08:45:36 +0200." 
Date: Fri, 17 Mar 2000 08:23:36 +0000
From: Colin Perkins 
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

--> Kimmo.Rantanen@lmf.ericsson.se writes:
>I like to add one more question:
>Is it absolutely necessary that both direction use the same type of
>codec ?

No.

Colin



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 11:30:44 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07649
	for ; Fri, 17 Mar 2000 11:30:41 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 49C0A52B6; Fri, 17 Mar 2000 11:27:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A98EC52C4; Fri, 17 Mar 2000 11:27:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 406D452B6
	for ; Fri, 17 Mar 2000 11:27:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 17 11:25:36 EST 2000
Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Fri Mar 17 11:25:34 EST 2000
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FRK00A8IQYLRC@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Fri, 17 Mar 2000 16:25:33 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FRK00301QYKB7@dgismtp01.wcomnet.com>;
 Fri, 17 Mar 2000 16:25:32 +0000 (GMT)
Received: from omzmta02.mcit.com ([166.37.214.8])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FRK0030VQY45T@dgismtp01.wcomnet.com>; Fri,
 17 Mar 2000 16:25:32 +0000 (GMT)
Received: from dwillispc8 ([166.35.148.173])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with SMTP id <20000317162511.FMKY7635@[166.35.148.173]>; Fri,
 17 Mar 2000 16:25:11 +0000
Date: Fri, 17 Mar 2000 10:24:26 -0600
From: Dean Willis 
Subject: Revised Agenda for SIP WG at IETF 47
To: IETF SIP 
Cc: Jonathan Rosenberg ,
        Joerg Ott 
Message-id: <003001bf902d$42ee3a20$ad9423a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: multipart/mixed; boundary="Boundary_(ID_pNCGp0NvE5VcOtTKCYqJMQ)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

This is a multi-part message in MIME format.

--Boundary_(ID_pNCGp0NvE5VcOtTKCYqJMQ)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


Ok, I asked for glaring errors in our first agenda draft, and YOU PEOPLE
FOUND SOME! Darn.

So, I've revised the agenda and posted it anew at:

http://www.softarmor.com/sipwg/meets/IETF47/agenda.html

and attached an HTML version to this email.

Note that we are getting a rather seriously packed agenda. I propose that we
settle further scheduling conflicts with noble denial-of-service duels at
dawn. Two kernels, one hub, pings of death . . .

--
Dean Willis
SIP WG co-chair

--Boundary_(ID_pNCGp0NvE5VcOtTKCYqJMQ)
Content-type: text/html; CHARSET=US-ASCII; name="Agenda, IETF 47, SIP WG.htm"
Content-disposition: attachment; filename="Agenda, IETF 47, SIP WG.htm"
Content-Transfer-Encoding: quoted-printable



Agenda, IETF 47, SIP WG




Agenda, IETF 47 SIP WG Session (Draft)


Proposed draft pending chair review.





Monday, March 27, 2000
0930 - 1130

<=
/TR>
  <=
/TR>
  <=
/TR>
  

  
  

    Presenter
    Title
    Time
    Contact

  

    Chairs
    Agenda Bashing
    0930
0:5		
    dean.willis@wcom.com

  

    Chairs
    Milestone Status
      

        
        

          Goal/
Status		
          
          Task

        

          Dec 99
Feb 00		
            
          INFO Method extension submitted to IESG 

        

          Feb 00
Soon		
            
          Early session establishment extension submitted to =
IESG

        

          Mar 00
Soon		
            
          Caller preferences specification submitted to =
IESG

        

          May 00
Open		
            
          Call control specification submitted to IESG

        

          Jul 00
Open		
            
          Draft standard version of SIP submitted to IESG

        

          Jul 00
open		
            
          SIP MIB submitted to IESG

    0935
0:5		
    dean.willis@wcom.com

  

    Chairs
    Charter Discussion
Consider as WG =
items, set=20
      milestones for:
      
    
        
  • SIP Server Features Negotiation=20
        
  • Call Flows (Informational)=20
        
  • SIP Session Timer=20
        
  • Reliability for Provisional Messages=20
        
  • SIP-Telephony=20
        
  • Convergence with the PacketCable DCS Spec (DCS=20
        Team)=20
        
  • Security=20
        
  • Single Line Extension  

    0940
0:5		
    dean.willis@wcom.com

  

    Jonathan Rosenberg
    WG status and current list =
topics
draft-nair-sip-dhcp-00.txt
other=20
      stuff from list		
    0945
0:15		
    jdrosen@dynamicsoft.com

    Jonathan Rosenberg 
    draft-ietf-sip-callerprefs-01.txt
WG=20
      charter item, review changes, no open issues, plan to last call =
following=20
      session timer and reliable provisional, schedule critical
draft-ietf-sip-serverfeatures-02.txt
Proposed=20
      WG charter item, ready for IESG
draft-ietf-sip-100rel-00.txt
Proposed=20
      WG charter item, review open issues, move quickly
draft-rosenberg-sip-guidelines-00.txt
Question:=20
      Interest in BCP track WG effort?
draft-rosenberg-sip-3pcc-00.txt
three-party=20
      call control, Question: WG task?		
    1000
0:30		
    jdrosen@dynamicsoft.com

    William Marshall
and the DCS =
Team		
    draft-dcsgroup-sip-arch-01.txt=20
      
draft-dcsgroup-sip-privacy-01.txt=20
      
draft-dcsgroup-sip-state-01.txt=20
      
draft-dcsgroup-sip-call-auth-01.txt=20
      
draft-dcsgroup-sip-proxy-proxy-01.txt=20
      draft-manyfolks-sip-resource-00.txt=20
    		
    1030
0:45		
    wtm@research.att.com

  

    Adam Roach
    draft-roach-sip-subscribe-notify-00.txt
    1115
0:10		
    adam.roach@ericsson.com

    Shinichi Baba 
    draft-itsumo-sip-mobility-req-00.txt
    1125
0:5		
    sbaba@tari.toshiba.com =


  

    Chairs
    Wrap
    1130
    


 


Tuesday, March 28, 2000
1300-1515

<=
/TR>
  

  
  

    Presenter
    Title
    Time
    Contact

  

    Chairs
    Intro and Agenda
    1300
0:05		
    dean.willis@wcom.com

  

    Steve Donovan
    draft-ietf-sip-info-method-01.txt
WG=20
      charter item, IESG, last call scheduled 3/18
=
draft-ietf-sip-183-00.txt=20
      (old draft)
WG charter item, review status, issues
Schedule=20
      critical
draft-ietf-sip-session-timer-01.txt
Proposed=20
      WG charter item, review changes, issues, move quick		
    1305
0:20		
    Steven.R.Donovan@wcom.com

  

    Robert Sparks
    draft-campbell-sip-cc-framework-00.txt
WG=20
      Charter Item, Schedule Critical
draft-sparks-sip-cc-transfer-00.txt
WG=20
      Charter Item, Schedule Critical
draft-campbell-sip-service-control-00.txt
draft-ietf-sip-call-flows-00a.txt		
    1325
0:30		
    robert.sparks@wcom.com
  

    Dave Walker
    =
draft-ietf-sip-mib-00.txt
WG=20
      Charter item		
    1355
0:15		
    drwalker@ss8networks.com

  

    TBD
    SIP-T Status Report
    1410
0:5		
    TBD

  

    Gonzalo Camarillo
    draft-camarillo-sip-isup-bcp-00.txt
Proposed=20
      WG charter item?		
    1415
0:10		
    gonzalo.camarillo@ercicss=
on.com

  

    James Polk
    draft-polk-sip-mlpp-mapping-00.txt
    1425
0:10		
    jmpolk@cisco.com 

  

    Henry Sinnreich 
    draft-sinnreich-sip-qos-osp-01.txt
    1435
0:10		
    henry.sinnreich@wcom.com

  

    Jonathan Rosenberg
    draft-lennox-sip-reg-payload-00.txt
draft-rosenberg-sip-firewalls-00.txt
Question;=20
      Interest in info track WG effort?
dr=
aft-rs-trip-gw-00.txt
intro=20
      of related draft from IPTEL		
    1445
0:30		
    jdrosen@dynamicsoft.com

    Jeff Mark 
    draft-mark-sip-dmcs-00.txt
    1515
0:10		
    mailto:[Jeff.Mark@Dialogic.com

  

    Chairs
    Wrap
    1525
    dean.willis@wcom.com





Revised March=20
18, 2000 04:12=20
GMT


--Boundary_(ID_pNCGp0NvE5VcOtTKCYqJMQ)--



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 12:24:05 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29536
	for ; Fri, 17 Mar 2000 12:24:03 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id C128052D4; Fri, 17 Mar 2000 12:21:31 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 2E5A152AB; Fri, 17 Mar 2000 12:21:31 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 4CC4652D4
	for ; Fri, 17 Mar 2000 12:21:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 17 12:20:03 EST 2000
Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Fri Mar 17 12:20:02 EST 2000
Received: from eclipse (adsl-63-199-31-222.dsl.snfc21.pacbell.net [63.199.31.222])
	by repulse.cnchost.com
	id MAA05027; Fri, 17 Mar 2000 12:19:58 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <001901bf9037$60ccd1a0$de1fc73f@eclipse>
From: "Sunitha Kumar" 
To: "Igor Slepchin" 
Cc: "SIPbell-labs" 
References: <38D198A6.14D3742C@vovida.com> <38D1B3F4.3C8CCA99@dynamicsoft.com>
Subject: Re: BYE and record route
Date: Fri, 17 Mar 2000 09:36:44 -0800
Organization: Vovida Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks for the pointers Igor. The documents really help.

----- Original Message ----- 
From: "Igor Slepchin" 
To: "Sunitha Kumar" 
Cc: "SIPbell-labs" 
Sent: Thursday, March 16, 2000 8:26 PM
Subject: Re: BYE and record route


> It certainly should, and not only for BYE requests. This is discussed in
> http://www.cs.columbia.edu/~hgs/sip/notes.html (see the note on
> Record-Route towards the end of the document) and in
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-2543bis-00.pdf
> (section 6.3.33).
> 
> ---
> Igor Slepchin
>  
> 
> Sunitha Kumar wrote:
> > 
> > It is given that the record route in 200 OK is copied into  the Route
> > headers for subsequent requests from the caller.  My question was, if
> > we needed to make the BYE from the *callee*  traverse the same set of
> > proxies, then  should this be rememberd from the INVITE request
> > obtained from the caller, or does the via field help in that.
> > 
> > Thanks!
> > 
> > --
> > Sunitha Kumar
> > Software Engineer
> > Vovida Networks
> > (408) 957 - 6374
> > 
> >
> 
> 




From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 12:34:07 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03138
	for ; Fri, 17 Mar 2000 12:34:05 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 4DD3B52AB; Fri, 17 Mar 2000 12:31:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B033252D5; Fri, 17 Mar 2000 12:31:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 84D0252AB
	for ; Fri, 17 Mar 2000 12:31:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 17 12:29:55 EST 2000
Received: from mw.3com.com ([149.112.20.3]) by dusty; Fri Mar 17 12:29:54 EST 2000
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id LAA10376; Fri, 17 Mar 2000 11:29:44 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 862568A5.00603FD4 ; Fri, 17 Mar 2000 11:31:17 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" 
To: sip@lists.research.bell-labs.com
Message-ID: <862568A5.00603DED.00@mwgate02.mw.3com.com>
Date: Fri, 17 Mar 2000 11:31:39 -0600
Subject: Why must a stateless proxy insert a Via header for itself.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk





Currently, the RFC states that every server in the path of a request must add
itself as a Via header.

As a stateless proxy, if this restriction is removed then I can process more
calls with faster call setup times.

So , can we make inserting itself as a Via optional for a stateless proxy.


Thanks,

Anoop





From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 12:52:01 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10833
	for ; Fri, 17 Mar 2000 12:52:00 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id AB15552C4; Fri, 17 Mar 2000 12:49:26 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 2E0E152D6; Fri, 17 Mar 2000 12:49:26 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 1D2F052C4
	for ; Fri, 17 Mar 2000 12:49:03 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 17 12:48:54 EST 2000
Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Fri Mar 17 12:48:53 EST 2000
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id MAA22773;
	Fri, 17 Mar 2000 12:48:17 -0500 (EST)
Message-ID: <38D26FE1.C1134EC9@cisco.com>
Date: Fri, 17 Mar 2000 12:48:17 -0500
From: Shail Bhatnagar 
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Anoop Tripathi 
Cc: sip@lists.research.bell-labs.com
Subject: Re: Why must a stateless proxy insert a Via header for itself.
References: <862568A5.00603DED.00@mwgate02.mw.3com.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Anoop Tripathi wrote:
> 
> Currently, the RFC states that every server in the path of a request must add
> itself as a Via header.
> 
> As a stateless proxy, if this restriction is removed then I can process more
> calls with faster call setup times.
> 
> So , can we make inserting itself as a Via optional for a stateless proxy.
> 
> Thanks,
> 
> Anoop

Then how do you do loop detection ??

-- 
Best regards,
Shail



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 13:59:54 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08941
	for ; Fri, 17 Mar 2000 13:59:53 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 7983A52D5; Fri, 17 Mar 2000 13:57:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id EEF4252D6; Fri, 17 Mar 2000 13:57:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id B11E952D5
	for ; Fri, 17 Mar 2000 13:57:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 17 13:56:14 EST 2000
Received: from mw.3com.com ([149.112.20.3]) by dusty; Fri Mar 17 13:56:13 EST 2000
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id MAA16961; Fri, 17 Mar 2000 12:55:56 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 862568A5.00682558 ; Fri, 17 Mar 2000 12:57:33 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Anoop Tripathi" 
To: Shail Bhatnagar 
Cc: sip@lists.research.bell-labs.com
Message-ID: <862568A5.006824A5.00@mwgate02.mw.3com.com>
Date: Fri, 17 Mar 2000 12:57:59 -0600
Subject: Re: Why must a stateless proxy insert a Via header for itself.
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk




Max-Forwards could be used to detect infinite loops.

Alternatively, what if we implement another header called "ResponsePath" .
 If a proxy wants to be in the path of the response it will include itself there
 ( On the same lines of Route header which are used for being in path of future
transactions).
The Via header could be used for loop detection.

Thanks,

Anoop




Shail Bhatnagar  on 03/17/2000 11:48:17 AM

Sent by:  Shail Bhatnagar 


To:   Anoop Tripathi/MW/US/3Com
cc:   sip@lists.research.bell-labs.com
Subject:  Re: Why must a stateless proxy insert a Via header for itself.



Anoop Tripathi wrote:
>
> Currently, the RFC states that every server in the path of a request must add
> itself as a Via header.
>
> As a stateless proxy, if this restriction is removed then I can process more
> calls with faster call setup times.
>
> So , can we make inserting itself as a Via optional for a stateless proxy.
>
> Thanks,
>
> Anoop

Then how do you do loop detection ??

--
Best regards,
Shail







From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 14:25:53 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20274
	for ; Fri, 17 Mar 2000 14:25:52 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 34FD952D6; Fri, 17 Mar 2000 14:23:20 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 93D7852DA; Fri, 17 Mar 2000 14:23:19 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 62C5052D6
	for ; Fri, 17 Mar 2000 14:23:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 17 14:21:46 EST 2000
Received: from blanc.cisco.com ([161.44.2.32]) by dusty; Fri Mar 17 14:21:45 EST 2000
Received: (ddaiker@localhost) by blanc.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id OAA01799; Fri, 17 Mar 2000 14:21:09 -0500 (EST)
From: David Daiker 
Message-Id: <200003171921.OAA01799@blanc.cisco.com>
Subject: Re: Why must a stateless proxy insert a Via header for itself.
To: Anoop_Tripathi@mw.3com.com (Anoop Tripathi)
Date: Fri, 17 Mar 2000 14:21:08 -0500 (EST)
Cc: sip@lists.research.bell-labs.com
In-Reply-To: <862568A5.00603DED.00@mwgate02.mw.3com.com> from "Anoop Tripathi" at Mar 17, 2000 11:31:39 AM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Anoop,

Just call your proxy a firewall, and then you don't have to.
Though, be advised that the next downstream UAS will add a 'received'
parameter to the topmost 'via' so you will see all subsequent responses
to this request.

regards,
david

> 
> Currently, the RFC states that every server in the path of a request must add
> itself as a Via header.
> 
> As a stateless proxy, if this restriction is removed then I can process more
> calls with faster call setup times.
> 
> So , can we make inserting itself as a Via optional for a stateless proxy.
> 
> 
> Thanks,
> 
> Anoop
> 
> 
> 
> 
> 




From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 16:37:44 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13732
	for ; Fri, 17 Mar 2000 16:37:43 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3FD0352E1; Fri, 17 Mar 2000 16:33:53 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9352352B6; Fri, 17 Mar 2000 16:33:52 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 2E8AE5306
	for ; Thu, 16 Mar 2000 22:45:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 16 22:44:27 EST 2000
Received: from web3406.mail.yahoo.com ([204.71.203.60]) by dusty; Thu Mar 16 22:44:27 EST 2000
Message-ID: <20000317034425.9180.qmail@web3406.mail.yahoo.com>
Received: from [202.54.89.85] by web3406.mail.yahoo.com; Thu, 16 Mar 2000 19:44:25 PST
Date: Thu, 16 Mar 2000 19:44:25 -0800 (PST)
From: Steve Little 
To: SIP Mailing List 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Hi all,
This Q is wrt construction of Route header by called
EP. (6.32.3, bis)
It mentions that while sending future requests, the
called EP copies the Record-Route entries into is
Route header preserving order.

So, If say from A(Calling)->B(Called), a request
from A took path A-P1-P2-P3-B, ie
Record-Route: P3, P2, P1
Then when B sends a BYE, it copies the Rec-Route as
Route: P3, P2, P1, A

Above makes sense. But what I dont understand is the
statement that URIs contaned in Rec-Route are not
useful in reverse path.
In the above example, am I not re-using the URLs in
the record-route for the reverse path ?
Also, Im not clear  what the statement
"However, all components except the maddr parameter
are replaced by the calling URI." means - calling URI
replaces what ? the Route list ? I guess not.

Thanks !


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 16:55:47 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20746
	for ; Fri, 17 Mar 2000 16:55:47 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3172452C8; Fri, 17 Mar 2000 16:53:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A110E52E0; Fri, 17 Mar 2000 16:53:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 639C652C8
	for ; Fri, 17 Mar 2000 16:53:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 17 16:51:12 EST 2000
Received: from redale.cisco.com ([171.71.154.68]) by dusty; Fri Mar 17 16:51:11 EST 2000
Received: from islain-ntl (dhcp-sjc9-232-204.cisco.com [171.71.232.204]) by redale.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id NAA22471; Fri, 17 Mar 2000 13:49:10 -0800 (PST)
Message-Id: <200003172149.NAA22471@redale.cisco.com>
X-Sender: islain@jindo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
Date: Fri, 17 Mar 2000 13:49:27 -0800
To: Robert.Sparks@wcom.com, "'Jonathan Rosenberg'" ,
        "'Henning Schulzrinne'" 
From: Ilya Slain 
Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)
Cc: sip@lists.research.bell-labs.com
In-Reply-To: <001301bf8f54$1ecc6600$999923a6@mcit.com>
References: <38D091C8.B596E724@dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


Robert,
Comment inline.

At 08:30 AM 3/16/00 -0600, Robert Sparks wrote:
>Jonathan Rosenberg writes:
>> However, I agree that the mechanism might have other uses besides
>> transfer, so something more functional would be nice. I also 
>> agree that
>> we should figure out the primitive functions we need to accomplish the
>> call control capabilities, and then specify extensions for the
>> primitives rather than the services. The services themselves 
>> can then be
>> described through informational documents that reference the 
>> extensions.
>> I think the idea proposed in the framework, of basically breaking call
>> control into separate pieces, is probably a good idea.
>
>I agree with specifying primatives rather than services.
>
>> I noted the following in the transfer draft:
>> > Explicit non-Requirements
>> > 
>> >    1. There is no requirement for the Transfer Target to be notified
>> >    that he is receiving an INVITE as the result of a 
>> TRANSFER request
>> >    (see comment 2).
>> 
>> Why? I really liked the idea of knowing that this call was 
>> the result of
>> a transfer, and knowing who the transferor was. A UA can always ignore
>> this information, and then get the basic service you have today. 
>
>I really like the idea too. Perhaps as part of the work right now we
>can capture knowing that the call was the result of a transfer (by adding
>an informational header to the invite - something that doesn't change
>the invite semantics), but my preference is to wait for direction from
>the SIP security task folks before addressing telling the transfer target
>who the transferor was.
>
>> The document says TRANSFER can't have a body. Why not? I can think of
>> some cool uses for this down the road. Why rule it out? 
>
>For consistency of implementation? (btw - One of those cool uses could be
>providing the identity of the transferor.)

Do you mean that this could be used for the Originator to
get the contact information of the Screener?  I would think
that hiding this information would be a good thing.


>The presence of a body 
>would likely affect the semantics of the operation (if it were honored,
>hence the consistency comment) through side-effects if not directly,
>so would it not make sense for the addition of a body to the base
>method be an actual extention? Perhaps the restriction should be
>loosened to allow any body which if processed, would not affect
>the behavior of the request?
>
>> 
>> The draft says:
>> > UA receiving a well-formed TRANSFER request SHOULD request approval
>> >    from the user to proceed. In the absence of that request, or upon
>> >    receiving approval from the user, the UA MUST submit an INVITE to
>> >    the resource identified by the Transfer-To: header using 
>> the Call-ID
>> >    from the TRANSFER request.
>> 
>> This thing about the Call-ID being copied from the TRANSFER 
>> seemed odd.
>> Why is that? If you wanted to accomplish this, it seems better to have
>> the URL in the Transfer-To header contain the Call-ID as a URL
>> parameter. In other words, why not do:
>> 
>> Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays
>
>Interesing thought! Can we explore your thinking more here?
>Using this, the TRANSFER would look like
>
>TRANSFER sip:transferee@transfereehost
>Transfer-To: sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
>Call-ID: abc@eeOrorhost
>
>Are you suggesting the subsequent invite look like this?
>
>INVITE sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
>Call-ID: def@eehost
>
>What would the request-URI parameter be used for then? I'm 
>not seeing obvious uses outside of event-logging.
>
>On reflection, I specified this copy because it resulted in
>a call-leg tuple that looked the same as it would have after
>a sip-cc-01 blind transfer. The motivation that draft had for
>this behavior may not apply here. Is there any value in keeping
>the Call-ID information accross this function (thinking of it
>as PLEASEINVITE instead of TRANSFER)?
>
>RjS
> 
____________________________________________________________________________

Ilya Slain                       ||        ||            Cisco Systems, Inc.
Technology Center               .||.      .||.                    Building 9
                               .||||.    .||||.        170 West Tasman Drive
Tel:    408.527.9446       ...||||||||..||||||||...      San Jose, CA  95134
Fax:    408.527.1221       C i s c o  S y s t e m s
E-Mail: islain@cisco.com
____________________________________________________________________________



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 17 17:41:54 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08593
	for ; Fri, 17 Mar 2000 17:41:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 51BD452B6; Fri, 17 Mar 2000 17:39:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id C9D1252E2; Fri, 17 Mar 2000 17:39:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 06D5752B6
	for ; Fri, 17 Mar 2000 17:39:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 17 17:37:13 EST 2000
Received: from mail-green.research.att.com ([135.207.30.103]) by dusty; Fri Mar 17 17:37:12 EST 2000
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-green.research.att.com (Postfix) with ESMTP id C7D7E1E016
	for ; Fri, 17 Mar 2000 17:37:11 -0500 (EST)
Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA16780
	for ; Fri, 17 Mar 2000 17:37:09 -0500 (EST)
From: William Marshall 
Received: (from wtm@localhost)
	by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id RAA24199
	for sip@lists.research.bell-labs.com; Fri, 17 Mar 2000 17:37:08 -0500 (EST)
Date: Fri, 17 Mar 2000 17:37:08 -0500 (EST)
Message-Id: <200003172237.RAA24199@fish-ha.research.att.com>
To: sip@lists.research.bell-labs.com
Subject: Re: clarifications on 183 and "manyfolks" drafts
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

> I can think of two ways to interpret the "Session: QoS" header.  ... 

Our interpretation of the "Session: QoS" header is that it carries
the SDP from the called party back to the calling party, so that both
endpoints can simultaneously establish QoS.  Once the QoS is established,
(unless a confirm attribute was requested) another 18x message is
sent from called party back to calling party to play ringback.

This is the second sample call flow in your email (attached below).

> Is the PRECONDITION-MET method from "manyfolks" intended to be used for all 
> QoS enabled sessions, or just those using the DCS Gateserver method of QoS?

The intention is that PRECONDITION-MET can be used for all types of QoS
setup protocols, including those that do not have a mechanism to reliably 
inform both endpoints of the success or failure of the request.  The
PRECONDITION-MET is also used to confirm all types of security associations,
that likewise may not have a mechanism to reliably inform both endpoints of the
success or failure of the request.

> Let say that A calls UserB@group.org, and a proxy forks INVITEs in parallel 
> to B, C, and D.  If A wants to establish QoS before ringing, how does the 
> proxy tell A about all the relevant session descriptions?

If the proxy forks the request to three endpoints, each of those endpoints
will send a 183-Session-Progress back to A, each including one SDP for
the media stream to them.  These are presumably distinguished by a tag
field in the call-leg identification.  A has the job of managing three
separate QoS reservations (or one reservation that can be used for three
destinations), depending on the interfaces it has available.  In general, I'd
expect three separate PRECONDITION-MET messages, one each to B, C, and D,
with the success/failure results for each.  No additional work for the proxy.

> If peers include a key (and crypto algorithm, key length, etc.) in the 
> session description (for example, using a k= tag in SDP), instead of later 
> using IKE to establish an SA, do they include "Session: Security"?

I don't see much distinction between "Session: QoS" and "Session: Security"
in the 183 message.  In both cases it means there is an SDP attached,
and the UAC needs to look at it and decide how to meet the preconditions.
If "a=security:mandatory" is in there, and a "k=" line too, meeting
the security precondition should be so easy the UAS shouldn't need a
confirmation (though it can ask for one anyway).

Bill Marshall
wtm@research.att.com

-----original message-----
Date: Wed, 15 Mar 2000 10:27:01 -0800
To: sip@lists.research.bell-labs.com
From: Rohan Mahy 
Subject: clarifications on 183 and "manyfolks" drafts

> 
> Hi,
> 
> There is a lot of emphasis in the 183 draft on interworking with the 
> PSTN.  Very little space is devoted to the Session: QoS and Session: 
> Security  headers though.
> 
> First issue/question:
> I can think of two ways to interpret the "Session: QoS" header.  The first 
> interpretation is that the user agent establishes QoS, and then once it has 
> been
> established, it does whatever it would normally do with that 18x message 
> (like ring or play ringback for a 180).
> 
> The second is that you would use a 183 first with Session: QoS or Security 
> to establish QoS or security, but you wouldn't do anything else about it. 
> Then once QoS is established, you could send a new 18x message to trigger 
> the desired behavior.
> 
> (Short call flows are below, assuming RSVP)
> Which method is correct (if either)?
> 
>   INVITE -->
>   <-- 180 Ringing (Session: QoS) [wait for QoS, then ring]
>   <-- PATH
>   PRACK (180)-->
>   PATH -->
>   RESV -->
>   <-- 200 OK (PRACK)
>   <-- RESV
>   <-- RESV CONF
>   [A plays ringback]
>   --> RESV CONF
>   [B alerts]
> 
>   or
> 
>   INVITE -->
>   <-- 183 Session Progress (Session: QoS) [wait for QoS, then send 180]
>   <-- PATH
>   PRACK (183)-->
>   PATH -->
>   RESV -->
>   <-- 200 OK (PRACK)
>   <-- RESV
>   <-- RESV CONF
>   --> RESV CONF
>   [B alerts]
>   <-- 180 Ringing
>   [A plays ringback]
>   PRACK (180) -->
>   <-- 200 OK (PRACK)
> 
> 
> Second question:
> Is the PRECONDITION-MET method from "manyfolks" intended to be used for all 
> QoS enabled sessions, or just those using the DCS Gateserver method of QoS?
> 
> 
> Third question/issue:
> Let say that A calls UserB@group.org, and a proxy forks INVITEs in parallel 
> to B, C, and D.  If A wants to establish QoS before ringing, how does the 
> proxy tell A about all the relevant session descriptions?
> 
> It seems that if the proxy just forwarded each 18x message with its session 
> description to A, that A would discard prior QoS relationships in favor of 
> the most recent. (Not what we want)
> 
> The proxy could send multiple session descriptions (multiple SDP bodies) in 
> a single 18x message to A.  If this is the right way to handle this 
> situation, I think it should be more explicitly defined. If this is 
> correct, would it be reasonable to put language in the next version of the 
> 183 draft that says that user agents MUST be able to deal with multiple SDP 
> bodies if they request Session: QoS?
> 
> 
> Last question/issue:
> If peers include a key (and crypto algorithm, key length, etc.) in the 
> session description (for example, using a k= tag in SDP), instead of later 
> using IKE to establish an SA, do they include "Session: Security"?
> 
> thanks,
> -rohan
> 
> 



From owner-sip-outgoing@lists.research.bell-labs.com  Sun Mar 19 11:06:17 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15873
	for ; Sun, 19 Mar 2000 11:06:17 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 33B4A52B6; Sun, 19 Mar 2000 11:03:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8ADBE52C8; Sun, 19 Mar 2000 11:03:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 1F16252B6
	for ; Sun, 19 Mar 2000 11:03:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 19 11:01:56 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Sun Mar 19 11:01:56 EST 2000
Received: from dynamicsoft.com (1Cust57.tnt3.freehold.nj.da.uu.net [63.25.172.57])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA00727;
	Sun, 19 Mar 2000 11:02:52 -0500 (EST)
Message-ID: <38D4FB7B.D2241CF7@dynamicsoft.com>
Date: Sun, 19 Mar 2000 11:08:27 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ken Carlberg 
Cc: "Rosen, Brian" , jmpolk@cisco.com,
        sip@lists.research.bell-labs.com
Subject: Re: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt
References: <200003161626.LAA06472@prima.time.saic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Ken Carlberg wrote:
> 
> > On your final thread, it should certainly be possible to define
> > an extension to SIP that is not useful in the PSTN; extensions
> > that are useful only within an enterprise for example should
> > be acceptable, or in the home, as well as something like MLPP
> > which is useful within a government communications system.
> 
> Agreed with respect to something that may or may not be "useful".  But the
> kicker that I'm curious about is whether the proposed specification is
> illegal (not allowed) when applied to the general public.

Here at IETF, we make protocols that run on the Internet, not the PSTN.
As there are no regulations regarding this kind of thing on the
Internet, it is not an issue for us. 

-Jonathan R.


-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Sun Mar 19 23:51:58 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06449
	for ; Sun, 19 Mar 2000 23:51:57 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3A48A52C4; Sun, 19 Mar 2000 23:49:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9F0EC52D4; Sun, 19 Mar 2000 23:49:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 71D6E52C4
	for ; Sun, 19 Mar 2000 23:49:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 19 23:47:38 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Sun Mar 19 23:47:37 EST 2000
Received: from dynamicsoft.com (1Cust94.tnt1.freehold.nj.da.uu.net [63.17.113.94])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA01061;
	Sun, 19 Mar 2000 23:48:44 -0500 (EST)
Message-ID: <38D5AEFE.3AEEAA66@dynamicsoft.com>
Date: Sun, 19 Mar 2000 23:54:22 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Little 
Cc: SIP Mailing List 
Subject: Re: 
References: <20000317034425.9180.qmail@web3406.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Steve Little wrote:
> 
> Hi all,
> This Q is wrt construction of Route header by called
> EP. (6.32.3, bis)
> It mentions that while sending future requests, the
> called EP copies the Record-Route entries into is
> Route header preserving order.
> 
> So, If say from A(Calling)->B(Called), a request
> from A took path A-P1-P2-P3-B, ie
> Record-Route: P3, P2, P1
> Then when B sends a BYE, it copies the Rec-Route as
> Route: P3, P2, P1, A
> 
> Above makes sense. But what I dont understand is the
> statement that URIs contaned in Rec-Route are not
> useful in reverse path.

Thats because these URIs all refer to addresses for B, not for A.
Remember, the Record-Route header is built by copying the request URI of
the request as it goes from A to B. So, lets be specific about your
example:

B is actually userB@company.com. So, A sends an INVITE like this:

INVITE sip:userB@company.com SIP/2.0
Contact: sip:userA@university.edu
....

to its local proxy P1. P1 looks up company.com (P2) and forwards it
there, and adds itself to the Record-Route. The forwarded request looks
like:

INVITE sip:userB@company.com SIP/2.0
Contact: sip:userA@university.edu
Record-Route: sip:userB@company.com;maddr=


Now, company.com (P2) checks for userB in its database, and finds that
this is Joe.B@sales.company.com. So, it adds itself to the Record-Route
and forwards the request to sales.company.com (P3):

INVITE sip:Joe.B@sales.company.com SIP/2.0
Contact: sip:userA@university.ede
Record-Route: sip:userB@company.com;maddr=
Record-Route: sip:userB@company.com;maddr=

Now, P3 (sales.company.com) knows where Joe is right now because of
registrations. Its sip:Joe.B@host3.sales.company.com. So, it adds itself
to the record-route and forwards it there:

INVITE sip:Joe.B@host3.sales.company.com SIP/2.0
Contact: sip:userA@university.ede
Record-Route: sip:Joe.B@sales.company.com;maddr=
Record-Route: sip:userB@company.com;maddr=
Record-Route: sip:userB@company.com;maddr=

now, it arrives at B (Joe.B@host3.sales.company.com), and the call is
up. Now, Joe wants to send that BYE to hang up. If, as you suggest, it
constructs the Route header with the same URI, the request it sends will
to P3 look like:

BYE sip:Joe.B@sales.company.com SIP/2.0
Route: sip:userB@company.com;maddr=
Route: sip:userB@company.com;maddr=
Route: sip:userA@university.edu

Note that the request URI of this request is actually B, not A. This
request above will actually be routed correctly, so long as (1) every
proxy obeys the route headers, (2) every proxy uses the maddr parameter.
If any proxy messes either up, the request is probably going to loop
back to B. Thats bad. Thus, the mechanism is brittle. By having the
called party construct the BYE in the following way:

BYE sip:userA@university.edu SIP/2.0
Route: sip:userA@university.edu;maddr=
Route: sip:userA@university.edu;maddr=
Route: sip:userA@university.edu

We guarantee things work right, even if any proxy ignores the Routes or
ignores maddr. The request is still routed correctly. Thats why its done
this way. We wish to preserve the rule that the request URI indicates
where the request is going.



> In the above example, am I not re-using the URLs in
> the record-route for the reverse path ?
> Also, Im not clear  what the statement
> "However, all components except the maddr parameter
> are replaced by the calling URI." means - calling URI
> replaces what ? the Route list ? I guess not.

I think the example clarifies this. Only the maddr parameter from the
Record-Route header is used when the UAS constructs the Route header.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 03:16:20 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01930
	for ; Mon, 20 Mar 2000 03:16:20 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 5F37A52D4; Mon, 20 Mar 2000 03:13:38 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D45FC52DA; Mon, 20 Mar 2000 03:13:37 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 78AC852D4
	for ; Mon, 20 Mar 2000 03:13:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 03:12:47 EST 2000
Received: from mailgw2.netvision.net.il ([194.90.1.9]) by dusty; Mon Mar 20 03:12:46 EST 2000
Received: from sendout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65])
	by mailgw2.netvision.net.il (8.9.3/8.9.3) with ESMTP id KAB11150
	for ; Mon, 20 Mar 2000 10:12:32 +0200 (IST)
Received: from ismail1.icomverse.com (ismail1.icomverse.com [190.190.110.2])
	by sendout.icomverse.com (8.9.3/8.8.7) with ESMTP id KAA13242
	for ; Mon, 20 Mar 2000 10:12:39 +0200
Received: by ismail1.icomverse.com with Internet Mail Service (5.5.2650.21)
	id <1RML3AMV>; Mon, 20 Mar 2000 10:12:27 +0200
Message-ID: 
From: "Gazal, Elly" 
To: "'sip@lists.research.bell-labs.com'" 
Subject: Message Waiting Indication Supplementary Service 
Date: Mon, 20 Mar 2000 10:12:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-8-i"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Can any one suggest how does Message Waiting Indication Supplementary
Service is achieved by SIP?

Regards,

Elly.



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 08:18:10 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22713
	for ; Mon, 20 Mar 2000 08:18:09 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id E7ED852D5; Mon, 20 Mar 2000 08:15:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 661E552DA; Mon, 20 Mar 2000 08:15:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id C2EE352D5
	for ; Mon, 20 Mar 2000 08:15:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 08:14:26 EST 2000
Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Mon Mar 20 08:14:26 EST 2000
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FRQ009I823SDS@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Mon, 20 Mar 2000 13:14:16 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FRQ00K0123RHX@dgismtp01.wcomnet.com>;
 Mon, 20 Mar 2000 13:14:16 +0000 (GMT)
Received: from omzmta04.mcit.com ([166.37.214.10])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FRQ00IE023RKT@dgismtp01.wcomnet.com>; Mon,
 20 Mar 2000 13:14:15 +0000 (GMT)
Received: from C25776A ([166.44.58.47])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000320131415.IIGY23037@C25776A>; Mon,
 20 Mar 2000 13:14:15 +0000
Date: Mon, 20 Mar 2000 07:14:10 -0600
From: Henry Sinnreich 
Subject: RE: SUA Completely Contained within IP networks proposal
In-reply-to: <01D91AFB08B6D211BFD00008C7EABAE1031DE7AD@eseis04nok>
To: john.loughney@NOKIA.COM, SIGTRAN@STANDARDS.NORTELNETWORKS.COM,
        sip@lists.research.bell-labs.com
Reply-To: henry.sinnreich@wcom.com
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Would be interested to compare this proposal with SIP/IP +
SIP-SS7 gateways.

What are the pros/cons from an overall systems view and
services?

Thanks, Henry

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081
USA

>-----Original Message-----
>From: Signaling Transport (sigtran)
>[mailto:SIGTRAN@STANDARDS.NORTELNETWORKS.COM]On Behalf
>Of John Loughney
>Sent: Monday, March 20, 2000 6:58 AM
>To: SIGTRAN@STANDARDS.NORTELNETWORKS.COM
>Subject: SUA Completely Contained within IP networks proposal
>
>
>Hi all,
>
>I recieved some comments about the SUA draft.  I have
>planned an
>architecture that would allow the transport of
>application protocols within
>an IP network.  This would remove the need for SG
>functioning.  This would
>be applicable for some situations.  There might be
>some situations where SS7
>addresses would still be used, but these SS7 addresses
>would be more logical
>than actual.  This situation would not restrict the
>architecture that I am
>proposing - but would be more of an implementation note.
>
>See the attached document for my proposal.
>
>cheers,
>John
>
>




From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 10:00:02 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08185
	for ; Mon, 20 Mar 2000 10:00:01 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id E4E8252DA; Mon, 20 Mar 2000 09:57:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6071052DC; Mon, 20 Mar 2000 09:57:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 65F9B52DA
	for ; Mon, 20 Mar 2000 09:57:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 09:56:13 EST 2000
Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Mon Mar 20 09:56:12 EST 2000
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FRQ00M4E6TN2K@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Mon, 20 Mar 2000 14:56:11 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with ESMTP id <0FRQ000016TMTD@dgismtp02.wcomnet.com>;
 Mon, 20 Mar 2000 14:56:11 +0000 (GMT)
Received: from omzmta02.mcit.com ([166.37.214.8])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0FRQ0005G6TH5Q@dgismtp02.wcomnet.com>; Mon,
 20 Mar 2000 14:56:10 +0000 (GMT)
Received: from sipdev4 ([166.35.153.153])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with SMTP id <20000320144704.HXJX22031@[166.35.153.153]>; Mon,
 20 Mar 2000 14:47:04 +0000
Date: Mon, 20 Mar 2000 08:42:03 -0600
From: Robert Sparks 
Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)
In-reply-to: <200003172149.NAA22471@redale.cisco.com>
To: "'Ilya Slain'" ,
        "'Jonathan Rosenberg'" ,
        "'Henning Schulzrinne'" 
Cc: sip@lists.research.bell-labs.com
Reply-To: Robert.Sparks@wcom.com
Message-id: <003801bf927a$755a97c0$999923a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ilya Slain writes:
> >For consistency of implementation? (btw - One of those cool 
> uses could be
> >providing the identity of the transferor.)
> 
> Do you mean that this could be used for the Originator to
> get the contact information of the Screener?  I would think
> that hiding this information would be a good thing.
> 
No - I was refering more to the function of the security token
in sip-cc-01. The transferor could provide a body with the
appropriate proof of who the TRANSFER originated from.

RjS



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 13:30:31 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01829
	for ; Mon, 20 Mar 2000 13:30:31 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 72AD552DB; Mon, 20 Mar 2000 13:27:09 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id C9FB552E0; Mon, 20 Mar 2000 13:27:08 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 9887352D6
	for ; Mon, 20 Mar 2000 05:25:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 05:24:17 EST 2000
Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Mon Mar 20 05:24:15 EST 2000
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id QAA25278;
	Mon, 20 Mar 2000 16:19:27 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652568A8.00390B06 ; Mon, 20 Mar 2000 15:53:03 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: "Gazal, Elly" 
Cc: "'sip@lists.research.bell-labs.com'" 
Message-ID: <652568A8.003909C9.00@sampark.hss.hns.com>
Date: Mon, 20 Mar 2000 15:52:59 +0530
Subject: Re: Message Waiting Indication Supplementary Service
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk



Hi,
I think one way is using the SUBSCRIBE-NOTIFY method
A UA subscribes to your "Messaging Centre" for receiving the indications
from any particular users or all of them.
The MC then sends NOTIFY messages to the subscribed UAs whenever an event
occurs (in this case, a message arriving)

Im not sure if any drafts already talk about Message Waiting using other
SIP extensions
but  I generally like the subscribe-notify concept for any notification as
above - although I dont think the scope of the
SUBSCRIBE/NOTIFY draft and its semantics are fixed yet (is this right ?)

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems









"Gazal, Elly"  on 03/20/2000 01:42:23 PM

To:   "'sip@lists.research.bell-labs.com'"
      
cc:

Subject:  Message Waiting Indication Supplementary Service




Can any one suggest how does Message Waiting Indication Supplementary
Service is achieved by SIP?

Regards,

Elly.








From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 13:33:23 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02996
	for ; Mon, 20 Mar 2000 13:33:22 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id D7BFC52E1; Mon, 20 Mar 2000 13:27:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id CC51252DE; Mon, 20 Mar 2000 13:27:17 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 1529652DA
	for ; Mon, 20 Mar 2000 08:31:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 08:30:11 EST 2000
Received: from mgw-x2.nokia.com ([131.228.20.22]) by dusty; Mon Mar 20 08:30:10 EST 2000
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id PAA19749;
	Mon, 20 Mar 2000 15:30:06 +0200 (EET)
From: john.loughney@nokia.com
Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244])
	by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id PAA28761;
	Mon, 20 Mar 2000 15:29:44 +0200 (EET)
Received: by esebh03nok with Internet Mail Service (5.5.2650.10)
	id ; Mon, 20 Mar 2000 15:29:43 +0200
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE1031DE7AF@eseis04nok>
To: henry.sinnreich@wcom.com, john.loughney@nokia.com,
        SIGTRAN@STANDARDS.NORTELNETWORKS.COM, sip@lists.research.bell-labs.com
Subject: RE: SUA Completely Contained within IP networks proposal
Date: Mon, 20 Mar 2000 15:29:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Hi Henry,

> Would be interested to compare this proposal with SIP/IP +
> SIP-SS7 gateways.

If you have a good document (draft) on this, I'd be more than
willing to make a comparison.  I have knowledge of SIP, but
not so detailed.
 
> What are the pros/cons from an overall systems view and
> services?

Well, I guess it depends on what protocols you need to carry.
Currently, in 3GPP, several protocols have been specified to
be carried over SCTP, so my proposal would be an additional
way to support them.  

Currently, the ITU is developing BICC (bearer independent call 
control) and one option would be to use SCTP for bearer 
service.  Some sort of adaptation layer would be needed for
support.

best regards,
John



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 13:59:56 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13981
	for ; Mon, 20 Mar 2000 13:59:55 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id D287B52DD; Mon, 20 Mar 2000 13:57:20 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5230452E0; Mon, 20 Mar 2000 13:57:20 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 7427352DD
	for ; Mon, 20 Mar 2000 13:57:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 20 13:55:52 EST 2000
Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Mon Mar 20 13:55:49 EST 2000
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA01425;
	Mon, 20 Mar 2000 10:55:48 -0800 (PST)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ABI04278;
	Mon, 20 Mar 2000 10:54:08 -0800 (PST)
Message-Id: <4.2.0.58.20000320101546.00bd7130@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 20 Mar 2000 10:55:11 -0800
To: William Marshall 
From: Rohan Mahy 
Subject: Re: clarifications on 183 and "manyfolks" drafts
Cc: sip@lists.research.bell-labs.com
In-Reply-To: <200003172237.RAA24199@fish-ha.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Hi,

Thanks for the reply.  Comments inline...

At 02:37 PM 3/17/00 , William Marshall wrote:
> > I can think of two ways to interpret the "Session: QoS" header.  ...
>
>Our interpretation of the "Session: QoS" header is that it carries
>the SDP from the called party back to the calling party, so that both
>endpoints can simultaneously establish QoS.  Once the QoS is established,
>(unless a confirm attribute was requested) another 18x message is
>sent from called party back to calling party to play ringback.

The 183 draft says you can use the Session header in any 18x message (with 
Media, QoS, or Security).  If your interpretation is correct, why would 
anyone ever use Session QoS with a 180 or 182?

>This is the second sample call flow in your email (attached below).
>
> > Is the PRECONDITION-MET method from "manyfolks" intended to be used for 
> all
> > QoS enabled sessions, or just those using the DCS Gateserver method of QoS?
>
>The intention is that PRECONDITION-MET can be used for all types of QoS
>setup protocols, including those that do not have a mechanism to reliably
>inform both endpoints of the success or failure of the request.  The
>PRECONDITION-MET is also used to confirm all types of security associations,
>that likewise may not have a mechanism to reliably inform both endpoints 
>of the
>success or failure of the request.

So it doesn't make sense to use PRECONDITION-MET if you are just using 
"plain-vanilla" RSVP or IKE. You take a hit for message efficiency, and you 
don't gain any functionality, yeah?

> > Let say that A calls UserB@group.org, and a proxy forks INVITEs in 
> parallel
> > to B, C, and D.  If A wants to establish QoS before ringing, how does the
> > proxy tell A about all the relevant session descriptions?
>
>If the proxy forks the request to three endpoints, each of those endpoints
>will send a 183-Session-Progress back to A, each including one SDP for
>the media stream to them.  These are presumably distinguished by a tag
>field in the call-leg identification.  A has the job of managing three
>separate QoS reservations (or one reservation that can be used for three
>destinations), depending on the interfaces it has available.  In general, I'd
>expect three separate PRECONDITION-MET messages, one each to B, C, and D,
>with the success/failure results for each.  No additional work for the proxy.

While this approach might work for a stateless proxy, I'm interested in the 
behavior of a stateful, parallel, forking proxy.  The behavior you 
described would be illegal (forwarding off the Via list) in this kind of 
proxy, since the INVITEs to B, C, & D would be sourced from the proxy, 
which would be the last stop on the Via list of each forked INVITE.  A 
would never see any responses to the proxy's forked INVITEs.

thanks,
-rohan

> > If peers include a key (and crypto algorithm, key length, etc.) in the
> > session description (for example, using a k= tag in SDP), instead of later
> > using IKE to establish an SA, do they include "Session: Security"?
>
>I don't see much distinction between "Session: QoS" and "Session: Security"
>in the 183 message.  In both cases it means there is an SDP attached,
>and the UAC needs to look at it and decide how to meet the preconditions.
>If "a=security:mandatory" is in there, and a "k=" line too, meeting
>the security precondition should be so easy the UAS shouldn't need a
>confirmation (though it can ask for one anyway).
>
>Bill Marshall
>wtm@research.att.com
>
>-----original message-----
>Date: Wed, 15 Mar 2000 10:27:01 -0800
>To: sip@lists.research.bell-labs.com
>From: Rohan Mahy 
>Subject: clarifications on 183 and "manyfolks" drafts
>
> >
> > Hi,
> >
> > There is a lot of emphasis in the 183 draft on interworking with the
> > PSTN.  Very little space is devoted to the Session: QoS and Session:
> > Security  headers though.
> >
> > First issue/question:
> > I can think of two ways to interpret the "Session: QoS" header.  The first
> > interpretation is that the user agent establishes QoS, and then once it 
> has
> > been
> > established, it does whatever it would normally do with that 18x message
> > (like ring or play ringback for a 180).
> >
> > The second is that you would use a 183 first with Session: QoS or Security
> > to establish QoS or security, but you wouldn't do anything else about it.
> > Then once QoS is established, you could send a new 18x message to trigger
> > the desired behavior.
> >
> > (Short call flows are below, assuming RSVP)
> > Which method is correct (if either)?
> >
> >   INVITE -->
> >   <-- 180 Ringing (Session: QoS) [wait for QoS, then ring]
> >   <-- PATH
> >   PRACK (180)-->
> >   PATH -->
> >   RESV -->
> >   <-- 200 OK (PRACK)
> >   <-- RESV
> >   <-- RESV CONF
> >   [A plays ringback]
> >   --> RESV CONF
> >   [B alerts]
> >
> >   or
> >
> >   INVITE -->
> >   <-- 183 Session Progress (Session: QoS) [wait for QoS, then send 180]
> >   <-- PATH
> >   PRACK (183)-->
> >   PATH -->
> >   RESV -->
> >   <-- 200 OK (PRACK)
> >   <-- RESV
> >   <-- RESV CONF
> >   --> RESV CONF
> >   [B alerts]
> >   <-- 180 Ringing
> >   [A plays ringback]
> >   PRACK (180) -->
> >   <-- 200 OK (PRACK)
> >
> >
> > Second question:
> > Is the PRECONDITION-MET method from "manyfolks" intended to be used for 
> all
> > QoS enabled sessions, or just those using the DCS Gateserver method of QoS?
> >
> >
> > Third question/issue:
> > Let say that A calls UserB@group.org, and a proxy forks INVITEs in 
> parallel
> > to B, C, and D.  If A wants to establish QoS before ringing, how does the
> > proxy tell A about all the relevant session descriptions?
> >
> > It seems that if the proxy just forwarded each 18x message with its 
> session
> > description to A, that A would discard prior QoS relationships in favor of
> > the most recent. (Not what we want)
> >
> > The proxy could send multiple session descriptions (multiple SDP 
> bodies) in
> > a single 18x message to A.  If this is the right way to handle this
> > situation, I think it should be more explicitly defined. If this is
> > correct, would it be reasonable to put language in the next version of the
> > 183 draft that says that user agents MUST be able to deal with multiple 
> SDP
> > bodies if they request Session: QoS?
> >
> >
> > Last question/issue:
> > If peers include a key (and crypto algorithm, key length, etc.) in the
> > session description (for example, using a k= tag in SDP), instead of later
> > using IKE to establish an SA, do they include "Session: Security"?
> >
> > thanks,
> > -rohan
> >
> >




From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 15:16:12 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13585
	for ; Mon, 20 Mar 2000 15:16:11 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 9BC1852DE; Mon, 20 Mar 2000 15:13:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id F061D52E2; Mon, 20 Mar 2000 15:13:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 4C08C52DE
	for ; Mon, 20 Mar 2000 15:13:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 15:11:50 EST 2000
Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Mon Mar 20 15:11:42 EST 2000
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA08881;
	Mon, 20 Mar 2000 15:11:40 -0500 (EST)
Message-ID: <38D685FC.61320995@cisco.com>
Date: Mon, 20 Mar 2000 15:11:40 -0500
From: Bryan Byerly 
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Cc: byerly@cisco.com, dwilli@cisco.com
Subject: New I-D: SIP Security using CHAP-Password
Content-Type: multipart/mixed;
 boundary="------------A3BD86621FBCF3B8A63A0BEC"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------A3BD86621FBCF3B8A63A0BEC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi guys,

Attached is an initial I-D on SIP Security using CHAP-Password.  This
I-D allows authentication of SIP clients using a backend Radius (RFC
2138) server.

I'd appreciate comments/criticisms/suggestions and I'd like to trigger a
discussion on the outstanding issues.

Enjoy!

Bryan

Bryan J. Byerly
byerly@cisco.com
(919) 392-7091


--------------A3BD86621FBCF3B8A63A0BEC
Content-Type: text/plain; charset=us-ascii;
 name="draft-byerly-sip-radius-00.txt"
Content-Disposition: inline;
 filename="draft-byerly-sip-radius-00.txt"
Content-Transfer-Encoding: 7bit

Internet Engineering Task Force                         Bryan J. Byerly
Internet Draft                                           David Williams
draft-byerly-sip-radius-00.txt                            Cisco Systems
March, 2000
Expires: September, 2000                                 
                                                      




                 SIP Security using CHAP-Password

Status of this Memo

  This document is an Internet-Draft and is in full conformance with
  all provisions of Section 10 of RFC2026.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups. Note that
  other groups may also distribute working documents as Internet-
  Drafts.

  Internet-Drafts are draft documents valid for a maximum of six 
  months and may be updated, replaced, or obsoleted by other documents 
  at any time. It is inappropriate to use Internet-Drafts as 
  reference material or to cite them other than as "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/lid-abstracts.txt.

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

Abstract

  This document describes a proposed extension to SIP.  This
  document proposes using an alternative SIP security mechanism
  for use in Proxy-Authorization or Authorization headers in order
  to support SIP client Authentication using backend RADIUS servers.

  The introduction of this extension would allow a SIP proxy
  (or called SIP client) to authenticate a SIP client using a backend
  RADIUS server.










Byerly/Williams      draft-byerly-sip-radius-00.txt               Page 1

Internet Draft       SIP Security using CHAP-Password         March 2000

1 Introduction

  Some ISPs currently use RADIUS servers to authenticate
  (and implicitly authorize) dialup users for PPP service.
  It would be advantageous to allow the re-use of this same
  RADIUS infrastructure for SIP client authentication.

  Although the currently defined mechanisms for SIP client
  authentication [section 3.2.2.2 of RFC 2617] and RADIUS
  authentication using a User-Password or CHAP-Password 
  [sections 5.2, 5.3 of RFC 2138] both use MD5, they run MD5
  across differently formatted messages.  There are two
  approaches to solving this problem.  One is to extend
  RADIUS to support HTTP-Digest; the other is to extend
  the SIP list of authentication schemes to support a CHAP-Password.
  This document proposes extending the SIP list of authentication
  schemes to support a CHAP-Password.


2 Definitions

  The definitions of several terms used in this document follow:

  nonce

      A nonce is a octet string that is uniquely generated each time a
      request is made.  It is recommended that a nonce be constructed
      to exhibit global and temporal uniqueness.

      The SIP specification [SIP] calls this a "nonce-value"
      (Section 3.2.1 of [DIG]).

      The RADIUS specification calls this a (random) challenge.
      (Section 2.2 of [RAD])
      In RADIUS, the nonce can be placed in the Request Authenticator
      (Section 4.2 of [RADIUS]) or in the CHAP-Challenge attribute.
      (Section 5.40 of [RADIUS])

      The CHAP Response in the CHAP-Password and the
      nonce-value in the HTTP-Digest use a 16-octet nonce.


  sequence number

     A sequence number is a monotonically increasing integer.
     Sequence numbers allow detection of replays.

     The "nonce-count" of the HTTP-Digest is a 32-bit sequence number
     (formatted as 8 hex digit characters)

     The "Chap-ID" in the CHAP-Password is a 1 octet sequence number.

Byerly/Williams      draft-byerly-sip-radius-00.txt               Page 2

Internet Draft       SIP Security using CHAP-Password         March 2000

  shared secret

      A secret shared between two entities.

      In this document, we assume that:

      - A user shares a secret (i.e. password) with
        the RADIUS server.

      - The PPP NAS (or SIP proxy) also shares a secret
        with the RADIUS server.


3 Analogous Model - PPP

  When a SIP proxy is used for user authentication
  an analogy can be drawn from PPP message flows.

3.1 Message flow for PPP user authentication with Radius backend:

  dialup                PPP                   RADIUS
  user                  NAS                   server
  |                      |                       |
  |--modem connection--->|                       |
  |                      |                       |
  |  PPP                 |                       |
  |<-Configure-Request---|                       |
  |                      |                       |
  |  PPP                 |                       |
  |--Configure-Ack------>|                       |
  |                      |                       |
  |                      |--Access-Request------>|
  |                      |                       |
  |                      |<-Access-Challenge-----|
  |                      |                       |
  |<-CHAP Challenge------|                       |
  |                      |                       |
  |--CHAP Response------>|                       |
  |                      |                       |
  |                      |--Access-Request------>|
  |                      |                       |
  |                      |<-Access-Accept--------|
  |                      |                       |
  |                      |                       |








Byerly/Williams      draft-byerly-sip-radius-00.txt               Page 3

Internet Draft       SIP Security using CHAP-Password         March 2000

3.2 Message flow for SIP user authentication with Radius backend:

  SIP                 SIP                     RADIUS
  client              proxy                   server
  |                      |                       |
  |--[1] INVITE--------->|                       |
  |                      |                       |
  |                      |--[2] Access-Request-->|
  |                      |                       |
  |                      |<-[3] Access-Challenge-|
  |                      |                       |
  |<-[4] 407-------------|                       |
  | (Proxy-Authenticate:)                        |
  |                      |                       |
  |--[5] INVITE--------->|                       |
  |(Proxy-Authorization:)                        |
  |                      |                       |
  |                      |--[6] Access-Request-->|
  |                      |                       |
  |                      |<-[7] Access-Accept----|
  |                      |                       |
  |                      |--[8] INVITE------------------>
  |                      |                       |
  .
  .
  .
  |<--200---------------|<--200------------------------

  When a PPP client authentication failure occurs, in some
  cases the PPP NAS implementation terminates the link.
  However, other PPP NAS implementations may choose to allow
  the client to continue, but with a filtered list of services.
  A PPP NAS may allow traffic which lets the user update his credentials
  (such as email to the sysadmin).

  Similarly, a SIP proxy server may wish to allow the user to place
  calls to the ISP's home office (to obtain updated credentials).
  A SIP proxy server may also wish to allow 911 calls to complete.


4 Current PAP/CHAP/SIP/HTTP Authentication mechanisms
  
  The following sections briefly describe the current mechanisms
  used for user authentication in PPP (PAP/CHAP) and HTTP/SIP
  (Basic and Digest).







Byerly/Williams      draft-byerly-sip-radius-00.txt               Page 4

Internet Draft       SIP Security using CHAP-Password         March 2000

4.1 PAP authentication mechanism

    Why not use RADIUS User-Password?

    The RADIUS User-Password attribute is calculated as:

        User-Password = md5hash(NAS-secret, nonce) XOR user-password

    If a PPP user sends his password in cleartext (eg. using PAP), then
    the PPP server can calculate the User-Password attribute of the
    Access-Request to authenticate the user.

    It is undesirable for a SIP user to send his password in cleartext.

    If the user does NOT send his password in cleartext, 
    the User-Password cannot be calculated by either the PPP client
    (because he doesn't know the NAS-secret) or the NAS
    (because he doesn't know the user-password).

4.2 CHAP authentication mechanism

    PPP defines usage of the CHAP-Password (as an alternative
    to User-Password) to avoid cleartext transmission of the
    users's password.

    When a CHAP-Password is used a cleartext sequence number, cleartext
    nonce, and the following MD5 hash are transmitted by the client:

        md5hash(seqnum, user-password, nonce)

    The nonce can be generated by the client or the server.
    If the nonce is generated by the client, the server may choose
    to accept it or may challenge the client with a new nonce.

4.3 SIP/HTTP authentication mechanisms:

    SIP and HTTP define two basic authentication mechanisms.
    HTTP-Basic and HTTP-Digest.  Usage of HTTP-Basic involves
    sending the the user's password in cleartext, and is thus
    undesirable.

    The currently defined mechanisms for SIP client authentication
    using HTTP-Digest are taken from section 3.2.2.2 of RFC 2617
    and the hash constructions are repeated here for
    clarity:

    If the directive's value is "MD5" or is unspecified, then A1 is:

       A1 = unq(username-value) ":" unq(realm-value) ":" passwd

    If the directive's value is "MD5-sess", then A1 is

Byerly/Williams      draft-byerly-sip-radius-00.txt               Page 5

Internet Draft       SIP Security using CHAP-Password         March 2000

    calculated only once - on the first request by the client following
    receipt of a WWW-Authenticate challenge from the server.  It uses
    the server nonce from the challenge, and the first client nonce
    value to construct A1 as follows:

       A1 = H( unq(username-value) ":" unq(realm-value)
                ":" passwd
                ":" unq(nonce-value) ":" unq(cnonce-value))

    This creates a 'session key' for the authentication of subsequent
    requests and responses which is different for each "authentication
    session", thus limiting the amount of material hashed with any one
    key. [RFC 2617]

5 Interaction/Mapping problems

  There are two problems:

  5.1 CHAP-Password construction problem:

      If a SIP proxy receives an HTTP-Digest from a SIP client
      (without CHAP-Password support), the SIP proxy is unable
      to construct a CHAP-Password.  This is because the SIP proxy
      doesn't have access to the client's password.
      The SIP proxy only has access to a hash of the client's password,
      and (as dicussed above) this hash is computed across a
      message whose format is different than the RADIUS server expects.

      Nor can the SIP proxy simply forward the hash calculated in
      the HTTP-Digest:

  5.2 Message mapping problem:

      Since the message format over which a hash is computed
      is different for the CHAP-Password than the message format
      used for the HTTP-Digest "MD5" or "MD5-sess" algorithms,
      a RADIUS server could not verify a proxied HTTP-Digest
      (which uses either the "MD5" or "MD5-sess" algorithms).
      The RADIUS server would discard such a HTTP-Digest
      formulated hash as invalid.

  Here is the proposed solution to these problems:

6 SIP Security using CHAP-Password

  To solve these problems, we specify an additional mechanism
  for SIP security which uses a CHAP-Password.  CHAP-Password
  can either be used for endpoint-to-endpoint authentication
  (when used in WWW-Authenticate and Authorization) or for
  endpoint-to-proxy authentication (when used in Proxy-Authenticate
  and Proxy-Authorization).

Byerly/Williams      draft-byerly-sip-radius-00.txt               Page 6

Internet Draft       SIP Security using CHAP-Password         March 2000

6.1 The WWW-Authenticate Response Header

    When a CHAP-Password is used for SIP security,
    the WWW-Authenticate Response Header (3.2.2 of RFC 2617)
    is defined as:

WWW-Authenticate = "WWW-Authenticate" ":" "CHAP-Password" chap-challenge
chap-challenge   = * (";" chap-params )
chap-params      = chap-username | chap-algorithm | chap-id | nonce
chap-algorithm   = "algorithm" "=" ( "MD5" | token )
chap-username    = quoted-string
chap-id          = "id" "=" + ( digit )
chap-nonce       = "nonce" "=" nonce-value
chap-nonce-value = <"> 32LHEX <">
LHEX             = "0" | "1" | "2" | "3" |
                   "4" | "5" | "6" | "7" |
                   "8" | "9" | "a" | "b" |
                   "c" | "d" | "e" | "f"

    chap-algorithm: A string indicating the authentication
                    method to be used.

    chap-username:  A string containing the user name.

    chap-id:        The CHAP Identifier is a one octet sequence number.

    nonce:          A string of 32 hex digits.  The contents of the
                    nonce are implementation dependent.  The quality
                    of the implementation depends on a good choice.
    Example: 

    WWW-Authenticate: CHAP-Password ;username="byerly" ;algorithm="MD5"
      ;id=0 ;nonce="10131973aaa511bb05261975aaa505fb"

    The chap-username is copied from the User-Name attribute
    of the Access-Challenge message received from the RADIUS server.

    The chap-id is copied from the (1-octet) Identifier field of the
    Access-Challenge message received from the RADIUS server.

    The chap-nonce-value is copied from the Access-Challenge message
    from the RADIUS server (from the CHAP-Challenge attribute if
    present, otherwise from the Request Authenticator).









Byerly/Williams      draft-byerly-sip-radius-00.txt               Page 7

Internet Draft       SIP Security using CHAP-Password         March 2000

6.2 The Authorization Request Header

    When challenged, the SIP client is expected to retry the request,
    passing an Authorization header line, which is defined as follows:

Authorization = "Authorization" ":" "CHAP-Password" chap-response-line
chap-response-line   =  * (";" chap-response-params )
chap-response-params = chap-username | chap-id | nonce | chap-response
chap-response        = "response" "=" chap-response-value
chap-response-value  = <"> 32LHEX <">

    chap-response-value: A string of 32 hex digits computed as defined
    in Section 4.1 of RFC1994, which proves that the user knows a
    password.

    Example:

    Authorization: CHAP-Password ;username="byerly" ;id=0
      ;nonce="10131973aaa511bb05261975aaa505fb"
      ;response="f53a66e43c12a383aa65219ec873ce35"
    
    The client MUST increment the CSeq header before resubmitting
    the request.

    A server MAY be configured not to generate nonces only if replay
    attacks are not a concern.

    The Response Value (chap-response-value) of the CHAP-Password is
    computed per Section 4.1 of RFC 1994 [CHAP].  The 16-octet
    Response Value of the CHAP-Password should be formatted as
    32 hex digits and placed in the "chap-response-value" of
    the Authorization request.

    The chap-id should be placed in the (1-octet) Identifier field
    of the Access-Request message to the RADIUS server.  The chap-id
    should also be placed in the (1-octet) CHAP Identifier field
    of the CHAP-Password attribute of the Access-Request message
    to the RADIUS server.  (See sections 3, 5.3, [RAD])

    The nonce-value SHOULD be placed in the Request Authenticator
    of the Access-Request message to the RADIUS server.
    (See section 3, [RAD])
    Alternatively, the nonce-value MAY be placed in a CHAP-Challenge
    attribute in the Access-Request message to the RADIUS server.
    (See section 5.3, [RAD])

    The chap-response-value should be placed in the 16-octet
    String field of the CHAP-Password attribute in the Access-Request
    message to the RADIUS server.  (See section 5.3, [RAD])




Byerly/Williams      draft-byerly-sip-radius-00.txt               Page 8

Internet Draft       SIP Security using CHAP-Password         March 2000

7 Proxy-Authenticate and Proxy-Authorization

  The CHAP-Password authentication scheme may also be used
  for authenticating users to proxies.

8 Security Considerations

  Security issues are the primary topic of this RFC.

  The security issues for this document are the same as those
  in the Security Considerations sections of RFC 1994 [CHAP]
  and RFC 2617 [DIG].

9 Further Examples

  Only the relevant headers have been included in the following 
  examples.

9.1 User Authentication using backend RADIUS server -
    With Server Challenge.

     [1] SIP Client to SIP proxy server:

          INVITE sip:+19195551212@cisco.com SIP/2.0
          From: sip:+19195551234@domain.com
          To: sip:+19195551212@cisco.com
          Call-ID: 12345600@cisco.com
          CSeq: 1 INVITE
          Proxy-Authorization: CHAP-Password
            ;username="byerly"
            ;algorithm="MD5"
            ;id=0
            ;nonce="aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
            ;response="bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
          Content-Type: application/sdp

NOTE: The Proxy-Authorization header sent in the first message
      may have been cached from a previous exchange with the
      SIP proxy.  If the SIP client does not place a
      Proxy-Authorization header in the INVITE, the RADIUS server will
      (transitting through SIP proxy) challenge him with a
      new nonce.

     [2] SIP proxy server to RADIUS server:

          Code = 1        (Access-Request)
          ID = 0
          Length = 71
          Request Authenticator = {16 octet random number also used as
                                   CHAP challenge
                                   (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)}

Byerly/Williams      draft-byerly-sip-radius-00.txt               Page 9

Internet Draft       SIP Security using CHAP-Password         March 2000

          Attributes:
              User-Name = "byerly"
              CHAP-Password = {1 octet CHAP ID (00) followed by 16 octet
                               CHAP response
                               (bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb)}
              NAS-IP-Address = 192.168.1.16
              NAS-Port = 5

     [3] RADIUS server to SIP proxy server:

          Code = 11       (Access-Challenge}
          ID = 0          (same as in Access-Request)
          Length = 68
          Attributes:
              Reply-Message = "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
              State = {Magic Cookie to be returned along with user's
                       response; in this example 8 octets of data}

     [4] SIP proxy server to client:

          SIP/2.0 407 Proxy Authentication required
          From: sip:+19195551234@domain.com
          To: sip:+19195551212@cisco.com
          Call-ID: 12345600@cisco.com
          CSeq: 1 INVITE
          Proxy-Authenticate: CHAP-Password
            ;username="byerly"
            ;algorithm="MD5"
            ;id=0
            ;nonce="cccccccccccccccccccccccccccccccc"
          State: {Magic Cookie from Access-Challenge packet, unchanged}
                 (formatted as hex digits)

NOTE: In this instance, the RADIUS server chooses to re-challenge
      the SIP client with a new nonce.

     [5] SIP Client to SIP proxy server:

          INVITE sip:+19195551212@cisco.com SIP/2.0
          From: sip:+19195551234@domain.com
          To: sip:+19195551212@cisco.com
          Call-ID: 12345600@cisco.com
          CSeq: 2 INVITE
          Content-Type: application/sdp
          Proxy-Authorization: CHAP-Password 
            ;username="byerly"
            ;algorithm="MD5"
            ;id=0
            ;nonce="cccccccccccccccccccccccccccccccc"
            ;response="dddddddddddddddddddddddddddddddd"
          State: {Magic Cookie from Access-Challenge packet, unchanged}
                 (formatted as hex digits)

Byerly/Williams      draft-byerly-sip-radius-00.txt              Page 10

Internet Draft       SIP Security using CHAP-Password         March 2000

     [6] SIP proxy server to RADIUS server:

          Code = 1        (Access-Request)
          ID = 1          (Note that this changes)
          Length = 71
          Request Authenticator = {NEW 16 octet CHAP challenge
                                   ()}
          Attributes:
              User-Name = "byerly"
              CHAP-Password = {1 octet CHAP ID followed by 16 octet
                               CHAP response
                               (dddddddddddddddddddddddddddddddd)}
              NAS-IP-Address = 192.168.1.16
              NAS-Port = 5
              State = {Magic Cookie from Access-Challenge packet,
                       unchanged}

     [7] RADIUS server to SIP proxy server:

          Code = 2        (Access-Accept)
          ID = 1          (same as in Access-Request)
          Length = 30

     [8] SIP proxy server to next hop UAS:

          INVITE sip:+19195551212@cisco.com SIP/2.0
          From: sip:+19195551234@domain.com
          To: sip:+19195551212@cisco.com
          Call-ID: 12345600@cisco.com
          CSeq: 2 INVITE
          Content-Type: application/sdp


9.2 User Authentication using backend RADIUS server -
    Without Server Challenge.

     [a] SIP Client to SIP proxy server:

          INVITE sip:+19195551212@cisco.com SIP/2.0
          From: sip:+19195551234@domain.com
          To: sip:+19195551212@cisco.com
          Call-ID: 12345601@cisco.com
          CSeq: 3 INVITE
          Proxy-Authorization: CHAP-Password 
            ;username="byerly"
            ;algorithm="MD5"
            ;id=0
            ;nonce="eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee"
            ;response="ffffffffffffffffffffffffffffffff"
          Content-Type: application/sdp



Byerly/Williams      draft-byerly-sip-radius-00.txt              Page 11

Internet Draft       SIP Security using CHAP-Password         March 2000

     [b] SIP proxy server to RADIUS server:

          Code = 1        (Access-Request)
          ID = 0
          Length = 71
          Request Authenticator = {16 octet random number also used as
                                   CHAP challenge
                                   (eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee)}
          Attributes:
              User-Name = "byerly"
              CHAP-Password = {1 octet CHAP ID (00) followed by 16 octet
                               CHAP response
                               (ffffffffffffffffffffffffffffffff)}
              NAS-IP-Address = 192.168.1.16
              NAS-Port = 5

     [c] RADIUS server to SIP proxy server:

          Code = 2        (Access-Accept)
          ID = 1          (same as in Access-Request)
          Length = 56

     [d] SIP proxy server to next hop UAS:

          INVITE sip:+19195551212@cisco.com SIP/2.0
          From: sip:+19195551234@domain.com
          To: sip:+19195551212@cisco.com
          Call-ID: 12345601@cisco.com
          CSeq: 3 INVITE
          Content-Type: application/sdp

     There are two cases when a SIP client could pre-send a
     Proxy-Authorization that the RADIUS server might accept:
     1) The RADIUS server originally generated the nonce
        when challenging the SIP client on a previous call.
        The SIP client is reusing the previously sucessful
        Authorization for a new call.
     2) The SIP client originally generated the nonce.
        The parsed format of the nonce is known to both the SIP
        client and the RADIUS server.  The nonce contains a timestamp
        which the RADIUS server can extract and use to limit the
        replay window.  Since a RADIUS server silently discards
        invalid/unauthorized requests, this scheme is not subject
        to the form of the man-in-the-middle attack where Mallory
        sends a bogus request to the server and uses the response
        to make the client believe she is a legitimate server.

     To dos:
     1) Fix the RADIUS Lengths to be correct
     2) Calculate real MD5 hashes



Byerly/Williams      draft-byerly-sip-radius-00.txt              Page 12

Internet Draft       SIP Security using CHAP-Password         March 2000

     Outstanding issues:
     1) Do we/how do we support the RADIUS State: attribute?
        What are the implications for collision with (DCS-)State:
        object?
     2) Do we reuse the RADIUS NAS-Port and NAS-Port-Type attributes to
        allow the RADIUS server to have media port control over calls?
        (eg. using UDP port numbers for RTP streams)


10 Acknowledgements

   We would like to thank Roger Levesque, David Oran, Mike Thomas,
   David Daiker, Shail Bhatnagar, and Denise Caballero-McCann for
   discussions on the need for and improvements to this draft.
   We would also like to thank Tyrone Floryanzia for his insights on
   H.323 gateway/gatekeeper call authorization using RADIUS.

11 References

[SIP]  M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, SIP: 
       Session Initiation Protocol", RFC 2543, March 1999.

[RAD]  C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote
       Authentication Dial in User Service (RADIUS)," RFC 2138,
       April 1997.

[DIG]  Franks, J, et al. "HTTP Authentication: Basic and Digest Access
       Authentication," RFC 2617, June 1999.

[CHAP] Simpson, W.  "PPP Challenge Handshake Authentication Protocol
       (CHAP)", RFC 1994, August 1996.

[PAP]  Lloyd, B, W. Simpson. "PPP Authentication Protocols",
       RFC 1334, October 1992.

[PPP]  Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
       51, RFC 1661, DayDreamer, July 1994.

[MD5]  Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
       MIT Laboratory for Computer Science and RSA Data Security,
       Inc., RFC 1321, April 1992.

[REQ]  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
       Levels," RFC-2119, March 1997.











Byerly/Williams      draft-byerly-sip-radius-00.txt              Page 13

Internet Draft       SIP Security using CHAP-Password         March 2000


Authors' Addresses

   Bryan J. Byerly
   Cisco Systems
   7025 Kit Creek Road
   P.O. Box 14987
   Research Triangle Park, NC 27709
   USA
   Email: byerly@cisco.com

   David Williams
   Cisco Systems
   7025 Kit Creek Road
   P.O. Box 14987
   Research Triangle Park, NC 27709
   USA
   Email: dwilli@cisco.com

--------------A3BD86621FBCF3B8A63A0BEC--




From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 15:25:55 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16759
	for ; Mon, 20 Mar 2000 15:25:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id F201652E3; Mon, 20 Mar 2000 15:23:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5FEFF52E2; Mon, 20 Mar 2000 15:23:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 81D0C52E3
	for ; Mon, 20 Mar 2000 15:23:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 15:22:32 EST 2000
Received: from mailgate.fore.com ([169.144.68.6]) by dusty; Mon Mar 20 15:22:31 EST 2000
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12])
	by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA07067;
	Mon, 20 Mar 2000 15:22:23 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
	by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA27452;
	Mon, 20 Mar 2000 15:22:25 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 20 Mar 2000 15:17:59 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF208B28@whq-msgusr-02.fore.com>
From: "Rosen, Brian" 
To: "'Bryan Byerly'" 
Cc: "'sip@lists.research.bell-labs.com'" 
Subject: RE: New I-D: SIP Security using CHAP-Password
Date: Mon, 20 Mar 2000 15:21:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

I don't have any specific beef with this idea.  
It has clear utility, especially if there is an 
existing RADIUS infrastructure.

I do want to open the question of whether having 
4 answers to the same (authentication) question is 
a good idea, regardless of the merits of any given 
answer.  What do you expect a SIPwriter to do?
Implement all of them?  Bet on one, two?

I'd prefer exactly one, even at the expense of 
deprecating proven, in the field solutions that are 
known to work.  I know, the problem is which one?  
I have my opinion, but it's more important that we 
decide if yet another security mechanism is 
appropriate at all.

I am indeed open to deciding that this is THE one.
It might not be my first choice, but it's better
than this plus 3, 4 or more others.

Brian

> -----Original Message-----
> From: Bryan Byerly [mailto:byerly@cisco.com]
> Sent: Monday, March 20, 2000 3:12 PM
> To: sip@lists.research.bell-labs.com
> Cc: byerly@cisco.com; dwilli@cisco.com
> Subject: New I-D: SIP Security using CHAP-Password
> 
> 
> Hi guys,
> 
> Attached is an initial I-D on SIP Security using CHAP-Password.  This
> I-D allows authentication of SIP clients using a backend Radius (RFC
> 2138) server.
> 
> I'd appreciate comments/criticisms/suggestions and I'd like 
> to trigger a
> discussion on the outstanding issues.
> 
> Enjoy!
> 
> Bryan
> 
> Bryan J. Byerly
> byerly@cisco.com
> (919) 392-7091
> 
> 



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 16:01:55 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01362
	for ; Mon, 20 Mar 2000 16:01:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 30E3A52E0; Mon, 20 Mar 2000 15:59:21 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9BC2052E5; Mon, 20 Mar 2000 15:59:20 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 136BD52E0
	for ; Mon, 20 Mar 2000 15:59:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 15:58:41 EST 2000
Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Mon Mar 20 15:58:27 EST 2000
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FRQ00DAQNL9A6@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Mon, 20 Mar 2000 20:58:26 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with ESMTP id <0FRQ00I01NL9PF@pmismtp01.wcomnet.com>;
 Mon, 20 Mar 2000 20:58:21 +0000 (GMT)
Received: from omzmta02.mcit.com ([166.37.214.8])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FRQ00GHNNL80F@pmismtp01.wcomnet.com>; Mon,
 20 Mar 2000 20:58:21 +0000 (GMT)
Received: from sipdev4 ([166.35.153.153])
 by omzmta02.mcit.com (InterMail v03.02.05 118 120)
 with SMTP id <20000320205818.DSRJ625@[166.35.153.153]>; Mon,
 20 Mar 2000 20:58:18 +0000
Date: Mon, 20 Mar 2000 14:53:21 -0600
From: Robert Sparks 
Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)
In-reply-to: <38D1CC33.43866C10@dynamicsoft.com>
To: "'Jonathan Rosenberg'" 
Cc: "'Henning Schulzrinne'" ,
        sip@lists.research.bell-labs.com
Reply-To: Robert.Sparks@wcom.com
Message-id: <005201bf92ae$54c49f40$999923a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> Robert Sparks wrote:
> > I really like the idea too. Perhaps as part of the work right now we
> > can capture knowing that the call was the result of a 
> transfer (by adding
> > an informational header to the invite - something that 
> doesn't change
> > the invite semantics), but my preference is to wait for 
> direction from
> > the SIP security task folks before addressing telling the 
> transfer target
> > who the transferor was.
> 
> There isn't going to be any magic poof that causes a solution to be
> generated. I think its the job of the author of the extension 
> to propose
> some security mechanism so that there can be a starting point for
> discussion.

OK - I guess I misunderstood what the security task force was 
supposed to be doing - I had expected an infrastructure as an
end result of their work. 

I am hesitant to integrate a new mechanism for proving the identity
of the transferor, or even reuse the pgp signature approach of 
sip-cc-01 if someone is working an infrastructure that should be used
instead. In any case, such a function should be generalized beyond
just this method, so, again, I am hesitant to place its definition
directly in this draft. Is this thinking way off base?


> > > The document says TRANSFER can't have a body. Why not? I 
> can think of
> > > some cool uses for this down the road. Why rule it out?
> > 
> > For consistency of implementation? (btw - One of those cool 
> uses could be
> > providing the identity of the transferor.) The presence of a body
> > would likely affect the semantics of the operation (if it 
> were honored,
> > hence the consistency comment) through side-effects if not directly,
> > so would it not make sense for the addition of a body to the base
> > method be an actual extention?
> 
> The presence of a body should not, in any way, alter the 
> basic semantics
> of the request. Treatment of a body in TRANSFER is no different than
> bodies in any other request. If the UAS doesn't know what to 
> do with it,
> it sends a 415. If it does know what to do with  it, it gets 
> processed.

In those cases where the side-effect of processing the body doesn't
affect the processing of the method (like displaying an optional
visual thumb of the caller), I agree. I have no problem changing
the wording of the draft to allow that kind of body part. However,
if you give meaning to the body parts in the context of processing the
message (such as we have right now with application/sdp - the presence
or absence of that body part affects the state of a receiving SIP engine),
I disagree. What happens when we come up with a body part that affects 
the processing of the method differently depending on the extention?

> > > This thing about the Call-ID being copied from the TRANSFER
> > > seemed odd.
> > > Why is that? If you wanted to accomplish this, it seems 
> better to have
> > > the URL in the Transfer-To header contain the Call-ID as a URL
> > > parameter. In other words, why not do:
> > >
> > > Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays
> > 
> > Interesing thought! Can we explore your thinking more here?
> > Using this, the TRANSFER would look like
> > 
> > TRANSFER sip:transferee@transfereehost
> > Transfer-To: sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
> > Call-ID: abc@eeOrorhost
> > 
> > Are you suggesting the subsequent invite look like this?
> > 
> > INVITE sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
> > Call-ID: def@eehost
> 
> No, like this:
> 
> INVITE sip:transfer-target@targethost
> Call-ID: abc@ee0rorhost
> 
> This way, the tranferror could ask the transferred party to add other
> headers or even body elements. 
> 

OK - I can see this for the other headers and body-elements, but for
Call-ID itself, are you not just adding redundant information to the
message? If its already in the Call-ID header in the request, how does
it help to have it also in the Request-URI? (My apologies if I'm being
dense).

Robert Sparks



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 16:11:49 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05319
	for ; Mon, 20 Mar 2000 16:11:49 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id CFB1652E5; Mon, 20 Mar 2000 16:09:21 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5041652E6; Mon, 20 Mar 2000 16:09:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id BD10E52E5
	for ; Mon, 20 Mar 2000 16:09:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 16:08:23 EST 2000
Received: from mw.3com.com ([149.112.20.3]) by dusty; Mon Mar 20 16:08:21 EST 2000
Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation)
	id PAA07041; Mon, 20 Mar 2000 15:07:19 -0600 (CST)
Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 862568A8.00742D5C ; Mon, 20 Mar 2000 15:08:57 -0600
X-Lotus-FromDomain: 3COM@3COM-MWGATE
From: "Jerry Mahler" 
To: Bryan Byerly 
Cc: sip@lists.research.bell-labs.com
Message-ID: <862568A8.00742C46.00@mwgate02.mw.3com.com>
Date: Mon, 20 Mar 2000 15:09:31 -0600
Subject: Re: New I-D: SIP Security using CHAP-Password
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk




Hey.

Well, you guys beat us to the punch.  We were also working on a SIP Chap draft
available at

     http://sip-happens.com/chap/draft-mahler-sip-chap-00.txt

One major difference is this draft includes the method and request URI of the
request in the hash of the response.  This is needed to prevent a
man-in-the-middle attack that would allow one to "hijack" a CHAP-authenticated
SIP session with one's own request URI.  We suggest you include this in future
versions of your draft.

Comments?

Jerry_Mahler@3com.com
(847)262-1030







Bryan Byerly  on 03/20/2000 02:11:40 PM

Sent by:  Bryan Byerly 


To:   sip@lists.research.bell-labs.com
cc:   byerly@cisco.com, dwilli@cisco.com (Jerry Mahler/MW/US/3Com)
Subject:  New I-D: SIP Security using CHAP-Password



Hi guys,

Attached is an initial I-D on SIP Security using CHAP-Password.  This
I-D allows authentication of SIP clients using a backend Radius (RFC
2138) server.

I'd appreciate comments/criticisms/suggestions and I'd like to trigger a
discussion on the outstanding issues.

Enjoy!

Bryan

Bryan J. Byerly
byerly@cisco.com
(919) 392-7091







From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 20:38:29 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14296
	for ; Mon, 20 Mar 2000 20:38:28 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 0887752D5; Mon, 20 Mar 2000 20:35:28 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6C4D452DB; Mon, 20 Mar 2000 20:35:27 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 68B2652DD
	for ; Mon, 20 Mar 2000 13:39:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 13:38:15 EST 2000
Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by dusty; Mon Mar 20 13:38:14 EST 2000
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA07506;
	Mon, 20 Mar 2000 10:38:12 -0800 (PST)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ABI04024;
	Mon, 20 Mar 2000 10:36:34 -0800 (PST)
Message-Id: <4.2.0.58.20000320103240.00c50530@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 20 Mar 2000 10:37:38 -0800
To: "Gazal, Elly" 
From: Rohan Mahy 
Subject: Re: Message Waiting Indication Supplementary Service 
Cc: "'sip@lists.research.bell-labs.com'" 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Hi,

Getting or checking the status of a voice mailbox is orthogonal to SIP's 
purpose (establishing sessions). You could use a separate protocol, or you 
could use either the SIP INFO or SUBSCRIBE/NOTIFY methods to provide 
supplemental information to the phone/endpoint.  You could use an XML, 
plain text, or other body type to convey this information, or an Event: header.

thanks,
-rohan


At 12:12 AM 3/20/00 , Gazal, Elly wrote:
>Can any one suggest how does Message Waiting Indication Supplementary
>Service is achieved by SIP?
>
>Regards,
>
>Elly.
>




From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 20 23:52:32 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27080
	for ; Mon, 20 Mar 2000 23:52:27 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id A0D5352C4; Mon, 20 Mar 2000 23:49:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 0EE9152D4; Mon, 20 Mar 2000 23:49:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 1263D52C4
	for ; Mon, 20 Mar 2000 23:49:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 20 23:48:16 EST 2000
Received: from mail-green.research.att.com ([135.207.30.103]) by dusty; Mon Mar 20 23:48:15 EST 2000
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 33BD71E01C; Mon, 20 Mar 2000 23:48:15 -0500 (EST)
Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id XAA09752;
	Mon, 20 Mar 2000 23:48:14 -0500 (EST)
From: William Marshall 
Received: (from wtm@localhost)
	by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id XAA83430;
	Mon, 20 Mar 2000 23:48:14 -0500 (EST)
Date: Mon, 20 Mar 2000 23:48:14 -0500 (EST)
Message-Id: <200003210448.XAA83430@fish-ha.research.att.com>
To: rohan@cisco.com
Subject: Re: clarifications on 183 and "manyfolks" drafts
Cc: sip@lists.research.bell-labs.com
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


> The 183 draft says you can use the Session header in any 18x message (with 
> Media, QoS, or Security).  If your interpretation is correct, why would 
> anyone ever use Session QoS with a 180 or 182?

Our draft says a response of 180 or 182 to the INVITE means the UAS doesn't
understand the preconditions, and UAC should do the best it can without them.
That part is independent of whether the 180/182 contained a Session: header
or not.

But what might it mean?  For cases where the media flow is one-way, UAC -> UAS,
it might be reasonable for the UAC to play ringback as soon as reservation is
complete, and UAS do the alterting on receipt of PRECONDITION-MET (i.e.
no additional 180-Ringing response.  However, my preference is for simplicity.

> 
> So it doesn't make sense to use PRECONDITION-MET if you are just using 
> "plain-vanilla" RSVP or IKE. You take a hit for message efficiency, and you 
> don't gain any functionality, yeah?
> 

There are two separate issues there.  First, one of your cisco colleagues 
pointed out that RESV-CONF is not a reliable message (sent via the "send 
and pray" transport mechanism) and very difficult to force a retransmission.  
The mechanism in this draft provides reliability to the message exchanges.

Second, the UAS needs to know whether the UAC will be using "plain-vanilla"
RSVP before it sends the request for a SIP confirmation in the 183.  How can it
know that?  That seems to be a hit for message efficiency there.  The
solution in the draft handles arbitrary reservation protocols, whether they
have a confirmation mechanism built in or not.  That seems a big gain in
functionality.

Bill Marshall
wtm@research.att.com


-----original message-----
Date: Mon, 20 Mar 2000 10:55:11 -0800
To: William Marshall 
From: Rohan Mahy 
Subject: Re: clarifications on 183 and "manyfolks" drafts
Cc: sip@lists.research.bell-labs.com
> 
> Hi,
> 
> Thanks for the reply.  Comments inline...
> 
> At 02:37 PM 3/17/00 , William Marshall wrote:
> > > I can think of two ways to interpret the "Session: QoS" header.  ...
> >
> >Our interpretation of the "Session: QoS" header is that it carries
> >the SDP from the called party back to the calling party, so that both
> >endpoints can simultaneously establish QoS.  Once the QoS is established,
> >(unless a confirm attribute was requested) another 18x message is
> >sent from called party back to calling party to play ringback.
> 
> The 183 draft says you can use the Session header in any 18x message (with 
> Media, QoS, or Security).  If your interpretation is correct, why would 
> anyone ever use Session QoS with a 180 or 182?
> 
> >This is the second sample call flow in your email (attached below).
> >
> > > Is the PRECONDITION-MET method from "manyfolks" intended to be used for 
> > all
> > > QoS enabled sessions, or just those using the DCS Gateserver method of QoS?
> >
> >The intention is that PRECONDITION-MET can be used for all types of QoS
> >setup protocols, including those that do not have a mechanism to reliably
> >inform both endpoints of the success or failure of the request.  The
> >PRECONDITION-MET is also used to confirm all types of security associations,
> >that likewise may not have a mechanism to reliably inform both endpoints 
> >of the
> >success or failure of the request.
> 
> So it doesn't make sense to use PRECONDITION-MET if you are just using 
> "plain-vanilla" RSVP or IKE. You take a hit for message efficiency, and you 
> don't gain any functionality, yeah?
> 
> > > Let say that A calls UserB@group.org, and a proxy forks INVITEs in 
> > parallel
> > > to B, C, and D.  If A wants to establish QoS before ringing, how does the
> > > proxy tell A about all the relevant session descriptions?
> >
> >If the proxy forks the request to three endpoints, each of those endpoints
> >will send a 183-Session-Progress back to A, each including one SDP for
> >the media stream to them.  These are presumably distinguished by a tag
> >field in the call-leg identification.  A has the job of managing three
> >separate QoS reservations (or one reservation that can be used for three
> >destinations), depending on the interfaces it has available.  In general, I'd
> >expect three separate PRECONDITION-MET messages, one each to B, C, and D,
> >with the success/failure results for each.  No additional work for the proxy.
> 
> While this approach might work for a stateless proxy, I'm interested in the 
> behavior of a stateful, parallel, forking proxy.  The behavior you 
> described would be illegal (forwarding off the Via list) in this kind of 
> proxy, since the INVITEs to B, C, & D would be sourced from the proxy, 
> which would be the last stop on the Via list of each forked INVITE.  A 
> would never see any responses to the proxy's forked INVITEs.
> 
> thanks,
> -rohan
> 
> > > If peers include a key (and crypto algorithm, key length, etc.) in the
> > > session description (for example, using a k= tag in SDP), instead of later
> > > using IKE to establish an SA, do they include "Session: Security"?
> >
> >I don't see much distinction between "Session: QoS" and "Session: Security"
> >in the 183 message.  In both cases it means there is an SDP attached,
> >and the UAC needs to look at it and decide how to meet the preconditions.
> >If "a=security:mandatory" is in there, and a "k=" line too, meeting
> >the security precondition should be so easy the UAS shouldn't need a
> >confirmation (though it can ask for one anyway).
> >
> >Bill Marshall
> >wtm@research.att.com
> >
> >-----original message-----
> >Date: Wed, 15 Mar 2000 10:27:01 -0800
> >To: sip@lists.research.bell-labs.com
> >From: Rohan Mahy 
> >Subject: clarifications on 183 and "manyfolks" drafts
> >
> > >
> > > Hi,
> > >
> > > There is a lot of emphasis in the 183 draft on interworking with the
> > > PSTN.  Very little space is devoted to the Session: QoS and Session:
> > > Security  headers though.
> > >
> > > First issue/question:
> > > I can think of two ways to interpret the "Session: QoS" header.  The first
> > > interpretation is that the user agent establishes QoS, and then once it 
> > has
> > > been
> > > established, it does whatever it would normally do with that 18x message
> > > (like ring or play ringback for a 180).
> > >
> > > The second is that you would use a 183 first with Session: QoS or Security
> > > to establish QoS or security, but you wouldn't do anything else about it.
> > > Then once QoS is established, you could send a new 18x message to trigger
> > > the desired behavior.
> > >
> > > (Short call flows are below, assuming RSVP)
> > > Which method is correct (if either)?
> > >
> > >   INVITE -->
> > >   <-- 180 Ringing (Session: QoS) [wait for QoS, then ring]
> > >   <-- PATH
> > >   PRACK (180)-->
> > >   PATH -->
> > >   RESV -->
> > >   <-- 200 OK (PRACK)
> > >   <-- RESV
> > >   <-- RESV CONF
> > >   [A plays ringback]
> > >   --> RESV CONF
> > >   [B alerts]
> > >
> > >   or
> > >
> > >   INVITE -->
> > >   <-- 183 Session Progress (Session: QoS) [wait for QoS, then send 180]
> > >   <-- PATH
> > >   PRACK (183)-->
> > >   PATH -->
> > >   RESV -->
> > >   <-- 200 OK (PRACK)
> > >   <-- RESV
> > >   <-- RESV CONF
> > >   --> RESV CONF
> > >   [B alerts]
> > >   <-- 180 Ringing
> > >   [A plays ringback]
> > >   PRACK (180) -->
> > >   <-- 200 OK (PRACK)
> > >
> > >
> > > Second question:
> > > Is the PRECONDITION-MET method from "manyfolks" intended to be used for 
> > all
> > > QoS enabled sessions, or just those using the DCS Gateserver method of QoS?
> > >
> > >
> > > Third question/issue:
> > > Let say that A calls UserB@group.org, and a proxy forks INVITEs in 
> > parallel
> > > to B, C, and D.  If A wants to establish QoS before ringing, how does the
> > > proxy tell A about all the relevant session descriptions?
> > >
> > > It seems that if the proxy just forwarded each 18x message with its 
> > session
> > > description to A, that A would discard prior QoS relationships in favor of
> > > the most recent. (Not what we want)
> > >
> > > The proxy could send multiple session descriptions (multiple SDP 
> > bodies) in
> > > a single 18x message to A.  If this is the right way to handle this
> > > situation, I think it should be more explicitly defined. If this is
> > > correct, would it be reasonable to put language in the next version of the
> > > 183 draft that says that user agents MUST be able to deal with multiple 
> > SDP
> > > bodies if they request Session: QoS?
> > >
> > >
> > > Last question/issue:
> > > If peers include a key (and crypto algorithm, key length, etc.) in the
> > > session description (for example, using a k= tag in SDP), instead of later
> > > using IKE to establish an SA, do they include "Session: Security"?
> > >
> > > thanks,
> > > -rohan
> > >
> > >
> 
> 



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 21 00:31:25 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11555
	for ; Tue, 21 Mar 2000 00:31:24 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 1E60B52D4; Tue, 21 Mar 2000 00:26:04 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6802052D5; Tue, 21 Mar 2000 00:26:03 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 12F7552D4
	for ; Tue, 21 Mar 2000 00:25:08 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 21 00:24:54 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Tue Mar 21 00:24:53 EST 2000
Received: from dynamicsoft.com (1Cust11.tnt3.freehold.nj.da.uu.net [63.25.172.11])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA03990
	for ; Tue, 21 Mar 2000 00:26:02 -0500 (EST)
Message-ID: <38D70941.2B727718@dynamicsoft.com>
Date: Tue, 21 Mar 2000 00:31:45 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: [Fwd: I-D ACTION:draft-rosenberg-sip-3pcc-00.txt]
Content-Type: multipart/mixed;
 boundary="------------CDED4B6F6FBADF73805B9406"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------CDED4B6F6FBADF73805B9406
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com
--------------CDED4B6F6FBADF73805B9406
Content-Type: message/rfc822
Content-Disposition: inline

Received: from wodc7mr4.ffx.ops.us.uu.net by wodc7ps1.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: wodc7mr4.ffx.ops.us.uu.net [192.48.96.29])
	id QQigyd05576
	for ; Fri, 17 Mar 2000 18:49:48 GMT
Received: from loki.ietf.org by wodc7mr4.ffx.ops.us.uu.net with ESMTP 
	(peer crosschecked as: loki.ietf.org [132.151.1.177])
	id QQigyd18361
	for ; Fri, 17 Mar 2000 18:49:48 GMT
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id MAA21693
	for ietf-123-outbound.02@ietf.org; Fri, 17 Mar 2000 12:55:00 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA17174
	for ; Fri, 17 Mar 2000 08:22:29 -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 IAA21994
	for ; Fri, 17 Mar 2000 08:22:29 -0500 (EST)
Message-Id: <200003171322.IAA21994@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce:;
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-rosenberg-sip-3pcc-00.txt
Date: Fri, 17 Mar 2000 08:22:29 -0500
Sender: nsyracus@cnri.reston.va.us
X-Mozilla-Status2: 00000000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Third Party Call Control in SIP
	Author(s)	: J. Rosenberg, H. Schulzrinne, J. Peterson
	Filename	: draft-rosenberg-sip-3pcc-00.txt
	Pages		: 11
	Date		: 16-Mar-00
	
This document discusses the usage of SIP for third party call
control. Third party call control refers to the ability of one entity
to create a call in which communications is actually between other
parties. We present a SIP mechanism for accomplishing third party
call control that does not require any extensions or changes to SIP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-3pcc-00.txt

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-rosenberg-sip-3pcc-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-rosenberg-sip-3pcc-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:	<20000316144510.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-rosenberg-sip-3pcc-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-rosenberg-sip-3pcc-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000316144510.I-D@ietf.org>

--OtherAccess--

--NextPart--




--------------CDED4B6F6FBADF73805B9406--




From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 21 04:40:05 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23878
	for ; Tue, 21 Mar 2000 04:40:05 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id D990252B6; Tue, 21 Mar 2000 04:37:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 487AA52DA; Tue, 21 Mar 2000 04:37:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 5890652B6
	for ; Tue, 21 Mar 2000 04:37:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 21 04:37:00 EST 2000
Received: from exchangesvr.nuera.com ([204.216.240.124]) by dusty; Tue Mar 21 04:36:59 EST 2000
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 21 Mar 2000 01:37:14 -0800
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Colin Perkins'" , Kimmo.Rantanen@lmf.ericsson.se
Cc: sip@lists.research.bell-labs.com
Subject: RE: Question on RTP
Date: Tue, 21 Mar 2000 01:37:13 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

		--> Kimmo.Rantanen@lmf.ericsson.se writes:
		>I like to add one more question:
		>Is it absolutely necessary that both direction use the same
type of
		>codec ?

		No.
		
		This is rather undesirable for vocoders or implementations
employing advanced echo cancellation, intelligent jitter buffer management
or a host of other DSP or voice-related properties.

		From my reading of the RFC, it is also equally possible for
either side to chop-and-change between vocoders at any point in time
(without SIP message exchange). Supporting this mixing and splicing of
vocoders significantly complicates the playback engine - the ability will
most likely be unsupported on simpler implementations or at best may cause
small audio glitches.

		It would be nice if the caller could force the callee to
agree on a single common vocoder if it doesn't support the use of multiple
vocoders. [Making the SDP session closer to a true two-way media exchange
rather than simply two disjoint vocoder packet flows in each direction.]

		One approach might be to place an updated SDP body in the
ACK where the SDP body has only one media format selected. The RFC currently
prohibits changing the SDP body in the ACK (unless the INVITE had no SDP
body). Does changing the body introduce any major problems or
inconsistencies ? 

		Furthermore, IMO it would be desirable if the callee could
indicate their vocoder preference by ordering the list of RTP media format
values in the 183/200 response.

		How have other people tackled this problem ? Are there any
drafts or FAQ on these subjects. 

		Cheers,

		Robert.
		 



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 21 04:48:07 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27044
	for ; Tue, 21 Mar 2000 04:48:06 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id CA43252DB; Tue, 21 Mar 2000 04:45:28 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 38D8D52DA; Tue, 21 Mar 2000 04:45:28 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 5E79F52DD
	for ; Tue, 21 Mar 2000 04:45:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 21 04:44:32 EST 2000
Received: from exchangesvr.nuera.com ([204.216.240.124]) by dusty; Tue Mar 21 04:44:32 EST 2000
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 21 Mar 2000 01:44:51 -0800
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "Fairlie-Cuninghame, Robert" ,
        "'Colin Perkins'" ,
        Kimmo.Rantanen@lmf.ericsson.se
Cc: sip@lists.research.bell-labs.com
Subject: RE: Question on RTP
Date: Tue, 21 Mar 2000 01:44:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Ahhh .. sorry, the message lost some quotation marks in the Microsoft
Outlook translation.

Just to clarify: The "No" at the top of the message was quoted from Colin
Perkins reply.

Robert.

		-----Original Message-----
		From:	Fairlie-Cuninghame, Robert
[mailto:rfairlie@nuera.com]
		Sent:	Tuesday, March 21, 2000 5:37 PM
		To:	'Colin Perkins'; Kimmo.Rantanen@lmf.ericsson.se
		Cc:	sip@lists.research.bell-labs.com
		Subject:	RE: Question on RTP

				--> Kimmo.Rantanen@lmf.ericsson.se writes:
				>I like to add one more question:
				>Is it absolutely necessary that both
direction use the same
		type of
				>codec ?

				No.
				
				This is rather undesirable for vocoders or
implementations
		employing advanced echo cancellation, intelligent jitter
buffer management
		or a host of other DSP or voice-related properties.

				From my reading of the RFC, it is also
equally possible for
		either side to chop-and-change between vocoders at any point
in time
		(without SIP message exchange). Supporting this mixing and
splicing of
		vocoders significantly complicates the playback engine - the
ability will
		most likely be unsupported on simpler implementations or at
best may cause
		small audio glitches.

				It would be nice if the caller could force
the callee to
		agree on a single common vocoder if it doesn't support the
use of multiple
		vocoders. [Making the SDP session closer to a true two-way
media exchange
		rather than simply two disjoint vocoder packet flows in each
direction.]

				One approach might be to place an updated
SDP body in the
		ACK where the SDP body has only one media format selected.
The RFC currently
		prohibits changing the SDP body in the ACK (unless the
INVITE had no SDP
		body). Does changing the body introduce any major problems
or
		inconsistencies ? 

				Furthermore, IMO it would be desirable if
the callee could
		indicate their vocoder preference by ordering the list of
RTP media format
		values in the 183/200 response.

				How have other people tackled this problem ?
Are there any
		drafts or FAQ on these subjects. 

				Cheers,

				Robert.
				 



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 21 10:42:15 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28701
	for ; Tue, 21 Mar 2000 10:42:14 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 28D2A52D5; Tue, 21 Mar 2000 10:39:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 943C352DD; Tue, 21 Mar 2000 10:39:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 99C4052D5
	for ; Tue, 21 Mar 2000 10:39:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 21 10:37:41 EST 2000
Received: from tonnant.cnchost.com ([207.155.248.72]) by dusty; Tue Mar 21 10:37:40 EST 2000
Received: from pc1 (gw-ss8networks.storm.ca [209.87.234.122])
	by tonnant.cnchost.com
	id KAA05252; Tue, 21 Mar 2000 10:37:29 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
From: "Li Li" 
To: 
Cc: , 
Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)
Date: Tue, 21 Mar 2000 10:38:53 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <005201bf92ae$54c49f40$999923a6@mcit.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Just a very simple question on the transfer flows in
the draft. Sorry for my limited understanding of this feature.
But is the reason for the INVITE(hold) from the transferor 
to the transferee just to tell him to hold (taking care of
the media path) and wait for a TRANSFER request (or later may 
be some other requests) to follow? So if the TRANSFER doesn't 
follow, what should be the behavior? Can we do without the 
INVITE(hold) message but just to use the TRANSFER with a (hold) 
to achieve the same thing? The transferee can respond to this 
TRANSFFER request to refuse the transfer. Or a 100 trying 
response tells the transferor he agrees to transfer and 
starts trying and holding the media path. The 200 OK response 
for the TRANSFER then tells the transferor that the transfer 
is successful. My two cents only. Correct me if I'm wrong.

Cheers,

li li 
SS8 Networks Ltd.
Kanata, Ont.
Canada
lili@ss8networks.com 

-----Original Message-----
From: owner-sip@lists.research.bell-labs.com
[mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Robert
Sparks
Sent: Monday, March 20, 2000 3:53 PM
To: 'Jonathan Rosenberg'
Cc: 'Henning Schulzrinne'; sip@lists.research.bell-labs.com
Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)


Jonathan Rosenberg wrote:
> Robert Sparks wrote:
> > I really like the idea too. Perhaps as part of the work right now we
> > can capture knowing that the call was the result of a 
> transfer (by adding
> > an informational header to the invite - something that 
> doesn't change
> > the invite semantics), but my preference is to wait for 
> direction from
> > the SIP security task folks before addressing telling the 
> transfer target
> > who the transferor was.
> 
> There isn't going to be any magic poof that causes a solution to be
> generated. I think its the job of the author of the extension 
> to propose
> some security mechanism so that there can be a starting point for
> discussion.

OK - I guess I misunderstood what the security task force was 
supposed to be doing - I had expected an infrastructure as an
end result of their work. 

I am hesitant to integrate a new mechanism for proving the identity
of the transferor, or even reuse the pgp signature approach of 
sip-cc-01 if someone is working an infrastructure that should be used
instead. In any case, such a function should be generalized beyond
just this method, so, again, I am hesitant to place its definition
directly in this draft. Is this thinking way off base?


> > > The document says TRANSFER can't have a body. Why not? I 
> can think of
> > > some cool uses for this down the road. Why rule it out?
> > 
> > For consistency of implementation? (btw - One of those cool 
> uses could be
> > providing the identity of the transferor.) The presence of a body
> > would likely affect the semantics of the operation (if it 
> were honored,
> > hence the consistency comment) through side-effects if not directly,
> > so would it not make sense for the addition of a body to the base
> > method be an actual extention?
> 
> The presence of a body should not, in any way, alter the 
> basic semantics
> of the request. Treatment of a body in TRANSFER is no different than
> bodies in any other request. If the UAS doesn't know what to 
> do with it,
> it sends a 415. If it does know what to do with  it, it gets 
> processed.

In those cases where the side-effect of processing the body doesn't
affect the processing of the method (like displaying an optional
visual thumb of the caller), I agree. I have no problem changing
the wording of the draft to allow that kind of body part. However,
if you give meaning to the body parts in the context of processing the
message (such as we have right now with application/sdp - the presence
or absence of that body part affects the state of a receiving SIP engine),
I disagree. What happens when we come up with a body part that affects 
the processing of the method differently depending on the extention?

> > > This thing about the Call-ID being copied from the TRANSFER
> > > seemed odd.
> > > Why is that? If you wanted to accomplish this, it seems 
> better to have
> > > the URL in the Transfer-To header contain the Call-ID as a URL
> > > parameter. In other words, why not do:
> > >
> > > Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays
> > 
> > Interesing thought! Can we explore your thinking more here?
> > Using this, the TRANSFER would look like
> > 
> > TRANSFER sip:transferee@transfereehost
> > Transfer-To: sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
> > Call-ID: abc@eeOrorhost
> > 
> > Are you suggesting the subsequent invite look like this?
> > 
> > INVITE sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
> > Call-ID: def@eehost
> 
> No, like this:
> 
> INVITE sip:transfer-target@targethost
> Call-ID: abc@ee0rorhost
> 
> This way, the tranferror could ask the transferred party to add other
> headers or even body elements. 
> 

OK - I can see this for the other headers and body-elements, but for
Call-ID itself, are you not just adding redundant information to the
message? If its already in the Call-ID header in the request, how does
it help to have it also in the Request-URI? (My apologies if I'm being
dense).

Robert Sparks





From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 21 12:06:08 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28753
	for ; Tue, 21 Mar 2000 12:06:06 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 8903F52B6; Tue, 21 Mar 2000 12:03:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 0779F52C4; Tue, 21 Mar 2000 12:03:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 46D4E52B6
	for ; Tue, 21 Mar 2000 12:03:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 21 12:02:06 EST 2000
Received: from tonnant.cnchost.com ([207.155.248.72]) by dusty; Tue Mar 21 12:02:03 EST 2000
Received: from pc1 (gw-ss8networks.storm.ca [209.87.234.122])
	by tonnant.cnchost.com
	id MAA29233; Tue, 21 Mar 2000 12:01:57 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
From: "Li Li" 
To: "Jonathan Rosenberg" ,
        
Cc: 
Subject: RE: comments on draft-rosenberg-sip-3pcc-00.txt
Date: Tue, 21 Mar 2000 12:03:22 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <38D70941.2B727718@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Indeed a very good and very useful feature. 
One question just for clarification.

When the controller sends the separate INVITE's
to the parties to be involved in the call, what
should be used in the from, to and call-id headers
to form the call leg? The two INVITE's may have 
the same call leg, which means the caler and callee
may not know there's a controller involved. 
That's be O.K. Or the controller can use different 
call legs with different from and to headers. 
This would mean that only the controller is
aware of the entire call with different legs. The 
caller and callee cannot send other requests for the
call directly to each other without going through
the controller? (not so good in some of the cases.)
It'll be better to make it clear in the draft.   



li li

Li Li
SS8 Networks Ltd. 
Kanata, Ontario, Canada
tel: 613 592 4686
email: lili@ss8networks.com 
-----Original Message-----
From: owner-sip@lists.research.bell-labs.com
[mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Jonathan
Rosenberg
Sent: Tuesday, March 21, 2000 12:32 AM
To: sip@lists.research.bell-labs.com
Subject: [Fwd: I-D ACTION:draft-rosenberg-sip-3pcc-00.txt]



-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 21 12:51:58 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16040
	for ; Tue, 21 Mar 2000 12:51:58 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 9AD8652B6; Tue, 21 Mar 2000 12:49:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 0E80C52D4; Tue, 21 Mar 2000 12:49:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id F2E8F52B6
	for ; Tue, 21 Mar 2000 12:49:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 21 12:48:10 EST 2000
Received: from dgesmtp01.wcom.com ([199.249.16.16]) by dusty; Tue Mar 21 12:48:09 EST 2000
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FRS00LGB9G78F@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Tue, 21 Mar 2000 17:48:07 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with ESMTP id <0FRS00D019G7NG@dgismtp02.wcomnet.com>;
 Tue, 21 Mar 2000 17:48:07 +0000 (GMT)
Received: from omta3.mcit.com ([166.37.204.5])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0FRS00BG09G6AN@dgismtp02.wcomnet.com>; Tue,
 21 Mar 2000 17:48:06 +0000 (GMT)
Received: from sipdev4 ([166.35.153.153])
 by omta3.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000321164501.FFJA454@sipdev4>; Tue, 21 Mar 2000 16:45:01 +0000
Date: Tue, 21 Mar 2000 10:39:42 -0600
From: Robert Sparks 
Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)
In-reply-to: 
To: "'Li Li'" 
Cc: jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com
Reply-To: Robert.Sparks@wcom.com
Message-id: <003201bf9354$0f919bc0$999923a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Allowing the media relationship between the transferee
and the transferor to be handled outside of the TRANSFER
transaction gives us the greatest flexibility. The examples
I gave showed terminating streams with holds, but other
scenarios may be appropriate depending on the capabilities
of the UA.

RjS

> -----Original Message-----
> From: Li Li [mailto:lili@ss8networks.com]
> Sent: Tuesday, March 21, 2000 9:39 AM
> To: Robert.Sparks@wcom.com
> Cc: jdrosen@dynamicsoft.com; sip@lists.research.bell-labs.com
> Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)
> 
> 
> Just a very simple question on the transfer flows in
> the draft. Sorry for my limited understanding of this feature.
> But is the reason for the INVITE(hold) from the transferor 
> to the transferee just to tell him to hold (taking care of
> the media path) and wait for a TRANSFER request (or later may 
> be some other requests) to follow? So if the TRANSFER doesn't 
> follow, what should be the behavior? Can we do without the 
> INVITE(hold) message but just to use the TRANSFER with a (hold) 
> to achieve the same thing? The transferee can respond to this 
> TRANSFFER request to refuse the transfer. Or a 100 trying 
> response tells the transferor he agrees to transfer and 
> starts trying and holding the media path. The 200 OK response 
> for the TRANSFER then tells the transferor that the transfer 
> is successful. My two cents only. Correct me if I'm wrong.
> 
> Cheers,
> 
> li li 
> SS8 Networks Ltd.
> Kanata, Ont.
> Canada
> lili@ss8networks.com 
> 
> -----Original Message-----
> From: owner-sip@lists.research.bell-labs.com
> [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Robert
> Sparks
> Sent: Monday, March 20, 2000 3:53 PM
> To: 'Jonathan Rosenberg'
> Cc: 'Henning Schulzrinne'; sip@lists.research.bell-labs.com
> Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)
> 
> 
> Jonathan Rosenberg wrote:
> > Robert Sparks wrote:
> > > I really like the idea too. Perhaps as part of the work 
> right now we
> > > can capture knowing that the call was the result of a 
> > transfer (by adding
> > > an informational header to the invite - something that 
> > doesn't change
> > > the invite semantics), but my preference is to wait for 
> > direction from
> > > the SIP security task folks before addressing telling the 
> > transfer target
> > > who the transferor was.
> > 
> > There isn't going to be any magic poof that causes a solution to be
> > generated. I think its the job of the author of the extension 
> > to propose
> > some security mechanism so that there can be a starting point for
> > discussion.
> 
> OK - I guess I misunderstood what the security task force was 
> supposed to be doing - I had expected an infrastructure as an
> end result of their work. 
> 
> I am hesitant to integrate a new mechanism for proving the identity
> of the transferor, or even reuse the pgp signature approach of 
> sip-cc-01 if someone is working an infrastructure that should be used
> instead. In any case, such a function should be generalized beyond
> just this method, so, again, I am hesitant to place its definition
> directly in this draft. Is this thinking way off base?
> 
> 
> > > > The document says TRANSFER can't have a body. Why not? I 
> > can think of
> > > > some cool uses for this down the road. Why rule it out?
> > > 
> > > For consistency of implementation? (btw - One of those cool 
> > uses could be
> > > providing the identity of the transferor.) The presence of a body
> > > would likely affect the semantics of the operation (if it 
> > were honored,
> > > hence the consistency comment) through side-effects if 
> not directly,
> > > so would it not make sense for the addition of a body to the base
> > > method be an actual extention?
> > 
> > The presence of a body should not, in any way, alter the 
> > basic semantics
> > of the request. Treatment of a body in TRANSFER is no different than
> > bodies in any other request. If the UAS doesn't know what to 
> > do with it,
> > it sends a 415. If it does know what to do with  it, it gets 
> > processed.
> 
> In those cases where the side-effect of processing the body doesn't
> affect the processing of the method (like displaying an optional
> visual thumb of the caller), I agree. I have no problem changing
> the wording of the draft to allow that kind of body part. However,
> if you give meaning to the body parts in the context of processing the
> message (such as we have right now with application/sdp - the presence
> or absence of that body part affects the state of a receiving 
> SIP engine),
> I disagree. What happens when we come up with a body part 
> that affects 
> the processing of the method differently depending on the extention?
> 
> > > > This thing about the Call-ID being copied from the TRANSFER
> > > > seemed odd.
> > > > Why is that? If you wanted to accomplish this, it seems 
> > better to have
> > > > the URL in the Transfer-To header contain the Call-ID as a URL
> > > > parameter. In other words, why not do:
> > > >
> > > > Transfer-To: sip:user@host?Call-ID=9nasd09asd--asdasd98ays
> > > 
> > > Interesing thought! Can we explore your thinking more here?
> > > Using this, the TRANSFER would look like
> > > 
> > > TRANSFER sip:transferee@transfereehost
> > > Transfer-To: sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
> > > Call-ID: abc@eeOrorhost
> > > 
> > > Are you suggesting the subsequent invite look like this?
> > > 
> > > INVITE sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
> > > Call-ID: def@eehost
> > 
> > No, like this:
> > 
> > INVITE sip:transfer-target@targethost
> > Call-ID: abc@ee0rorhost
> > 
> > This way, the tranferror could ask the transferred party to 
> add other
> > headers or even body elements. 
> > 
> 
> OK - I can see this for the other headers and body-elements, but for
> Call-ID itself, are you not just adding redundant information to the
> message? If its already in the Call-ID header in the request, how does
> it help to have it also in the Request-URI? (My apologies if I'm being
> dense).
> 
> Robert Sparks
> 
> 



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 21 14:18:07 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20321
	for ; Tue, 21 Mar 2000 14:18:06 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 71BE352C4; Tue, 21 Mar 2000 14:15:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id E012C52D4; Tue, 21 Mar 2000 14:15:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id B42AE52C4
	for ; Tue, 21 Mar 2000 14:15:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 21 14:13:29 EST 2000
Received: from sj-mailhub-3.cisco.com ([171.68.224.215]) by dusty; Tue Mar 21 14:13:28 EST 2000
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA25586;
	Tue, 21 Mar 2000 11:39:44 -0800 (PST)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ABL01084;
	Tue, 21 Mar 2000 11:11:30 -0800 (PST)
Message-Id: <4.2.0.58.20000321110328.00be9240@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 21 Mar 2000 11:12:35 -0800
To: William Marshall 
From: Rohan Mahy 
Subject: Re: clarifications on 183 and "manyfolks" drafts
Cc: sip@lists.research.bell-labs.com
In-Reply-To: <200003210448.XAA83430@fish-ha.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Hi,

OK, I get the need for preconditions.  We still need to get session 
descriptions from B,C, and D to A.  My proposal was sending these in one 
183 with multiple bodies.  Is this reasonable?

thanks,
-rohan


At 08:48 PM 3/20/00 , William Marshall wrote:

> > The 183 draft says you can use the Session header in any 18x message (with
> > Media, QoS, or Security).  If your interpretation is correct, why would
> > anyone ever use Session QoS with a 180 or 182?
>
>Our draft says a response of 180 or 182 to the INVITE means the UAS doesn't
>understand the preconditions, and UAC should do the best it can without them.
>That part is independent of whether the 180/182 contained a Session: header
>or not.
>
>But what might it mean?  For cases where the media flow is one-way, UAC -> 
>UAS,
>it might be reasonable for the UAC to play ringback as soon as reservation is
>complete, and UAS do the alterting on receipt of PRECONDITION-MET (i.e.
>no additional 180-Ringing response.  However, my preference is for simplicity.
>
> >
> > So it doesn't make sense to use PRECONDITION-MET if you are just using
> > "plain-vanilla" RSVP or IKE. You take a hit for message efficiency, and 
> you
> > don't gain any functionality, yeah?
> >
>
>There are two separate issues there.  First, one of your cisco colleagues
>pointed out that RESV-CONF is not a reliable message (sent via the "send
>and pray" transport mechanism) and very difficult to force a retransmission.
>The mechanism in this draft provides reliability to the message exchanges.
>
>Second, the UAS needs to know whether the UAC will be using "plain-vanilla"
>RSVP before it sends the request for a SIP confirmation in the 183.  How 
>can it
>know that?  That seems to be a hit for message efficiency there.  The
>solution in the draft handles arbitrary reservation protocols, whether they
>have a confirmation mechanism built in or not.  That seems a big gain in
>functionality.
>
>Bill Marshall
>wtm@research.att.com
>
>
>-----original message-----
>Date: Mon, 20 Mar 2000 10:55:11 -0800
>To: William Marshall 
>From: Rohan Mahy 
>Subject: Re: clarifications on 183 and "manyfolks" drafts
>Cc: sip@lists.research.bell-labs.com
> >
> > Hi,
> >
> > Thanks for the reply.  Comments inline...
> >
> > At 02:37 PM 3/17/00 , William Marshall wrote:
> > > > I can think of two ways to interpret the "Session: QoS" header.  ...
> > >
> > >Our interpretation of the "Session: QoS" header is that it carries
> > >the SDP from the called party back to the calling party, so that both
> > >endpoints can simultaneously establish QoS.  Once the QoS is established,
> > >(unless a confirm attribute was requested) another 18x message is
> > >sent from called party back to calling party to play ringback.
> >
> > The 183 draft says you can use the Session header in any 18x message (with
> > Media, QoS, or Security).  If your interpretation is correct, why would
> > anyone ever use Session QoS with a 180 or 182?
> >
> > >This is the second sample call flow in your email (attached below).
> > >
> > > > Is the PRECONDITION-MET method from "manyfolks" intended to be used 
> for
> > > all
> > > > QoS enabled sessions, or just those using the DCS Gateserver method 
> of QoS?
> > >
> > >The intention is that PRECONDITION-MET can be used for all types of QoS
> > >setup protocols, including those that do not have a mechanism to reliably
> > >inform both endpoints of the success or failure of the request.  The
> > >PRECONDITION-MET is also used to confirm all types of security 
> associations,
> > >that likewise may not have a mechanism to reliably inform both endpoints
> > >of the
> > >success or failure of the request.
> >
> > So it doesn't make sense to use PRECONDITION-MET if you are just using
> > "plain-vanilla" RSVP or IKE. You take a hit for message efficiency, and 
> you
> > don't gain any functionality, yeah?
> >
> > > > Let say that A calls UserB@group.org, and a proxy forks INVITEs in
> > > parallel
> > > > to B, C, and D.  If A wants to establish QoS before ringing, how 
> does the
> > > > proxy tell A about all the relevant session descriptions?
> > >
> > >If the proxy forks the request to three endpoints, each of those endpoints
> > >will send a 183-Session-Progress back to A, each including one SDP for
> > >the media stream to them.  These are presumably distinguished by a tag
> > >field in the call-leg identification.  A has the job of managing three
> > >separate QoS reservations (or one reservation that can be used for three
> > >destinations), depending on the interfaces it has available.  In 
> general, I'd
> > >expect three separate PRECONDITION-MET messages, one each to B, C, and D,
> > >with the success/failure results for each.  No additional work for the 
> proxy.
> >
> > While this approach might work for a stateless proxy, I'm interested in 
> the
> > behavior of a stateful, parallel, forking proxy.  The behavior you
> > described would be illegal (forwarding off the Via list) in this kind of
> > proxy, since the INVITEs to B, C, & D would be sourced from the proxy,
> > which would be the last stop on the Via list of each forked INVITE.  A
> > would never see any responses to the proxy's forked INVITEs.
> >
> > thanks,
> > -rohan
> >
> > > > If peers include a key (and crypto algorithm, key length, etc.) in the
> > > > session description (for example, using a k= tag in SDP), instead 
> of later
> > > > using IKE to establish an SA, do they include "Session: Security"?
> > >
> > >I don't see much distinction between "Session: QoS" and "Session: 
> Security"
> > >in the 183 message.  In both cases it means there is an SDP attached,
> > >and the UAC needs to look at it and decide how to meet the preconditions.
> > >If "a=security:mandatory" is in there, and a "k=" line too, meeting
> > >the security precondition should be so easy the UAS shouldn't need a
> > >confirmation (though it can ask for one anyway).
> > >
> > >Bill Marshall
> > >wtm@research.att.com
> > >
> > >-----original message-----
> > >Date: Wed, 15 Mar 2000 10:27:01 -0800
> > >To: sip@lists.research.bell-labs.com
> > >From: Rohan Mahy 
> > >Subject: clarifications on 183 and "manyfolks" drafts
> > >
> > > >
> > > > Hi,
> > > >
> > > > There is a lot of emphasis in the 183 draft on interworking with the
> > > > PSTN.  Very little space is devoted to the Session: QoS and Session:
> > > > Security  headers though.
> > > >
> > > > First issue/question:
> > > > I can think of two ways to interpret the "Session: QoS" 
> header.  The first
> > > > interpretation is that the user agent establishes QoS, and then 
> once it
> > > has
> > > > been
> > > > established, it does whatever it would normally do with that 18x 
> message
> > > > (like ring or play ringback for a 180).
> > > >
> > > > The second is that you would use a 183 first with Session: QoS or 
> Security
> > > > to establish QoS or security, but you wouldn't do anything else 
> about it.
> > > > Then once QoS is established, you could send a new 18x message to 
> trigger
> > > > the desired behavior.
> > > >
> > > > (Short call flows are below, assuming RSVP)
> > > > Which method is correct (if either)?
> > > >
> > > >   INVITE -->
> > > >   <-- 180 Ringing (Session: QoS) [wait for QoS, then ring]
> > > >   <-- PATH
> > > >   PRACK (180)-->
> > > >   PATH -->
> > > >   RESV -->
> > > >   <-- 200 OK (PRACK)
> > > >   <-- RESV
> > > >   <-- RESV CONF
> > > >   [A plays ringback]
> > > >   --> RESV CONF
> > > >   [B alerts]
> > > >
> > > >   or
> > > >
> > > >   INVITE -->
> > > >   <-- 183 Session Progress (Session: QoS) [wait for QoS, then send 180]
> > > >   <-- PATH
> > > >   PRACK (183)-->
> > > >   PATH -->
> > > >   RESV -->
> > > >   <-- 200 OK (PRACK)
> > > >   <-- RESV
> > > >   <-- RESV CONF
> > > >   --> RESV CONF
> > > >   [B alerts]
> > > >   <-- 180 Ringing
> > > >   [A plays ringback]
> > > >   PRACK (180) -->
> > > >   <-- 200 OK (PRACK)
> > > >
> > > >
> > > > Second question:
> > > > Is the PRECONDITION-MET method from "manyfolks" intended to be used 
> for
> > > all
> > > > QoS enabled sessions, or just those using the DCS Gateserver method 
> of QoS?
> > > >
> > > >
> > > > Third question/issue:
> > > > Let say that A calls UserB@group.org, and a proxy forks INVITEs in
> > > parallel
> > > > to B, C, and D.  If A wants to establish QoS before ringing, how 
> does the
> > > > proxy tell A about all the relevant session descriptions?
> > > >
> > > > It seems that if the proxy just forwarded each 18x message with its
> > > session
> > > > description to A, that A would discard prior QoS relationships in 
> favor of
> > > > the most recent. (Not what we want)
> > > >
> > > > The proxy could send multiple session descriptions (multiple SDP
> > > bodies) in
> > > > a single 18x message to A.  If this is the right way to handle this
> > > > situation, I think it should be more explicitly defined. If this is
> > > > correct, would it be reasonable to put language in the next version 
> of the
> > > > 183 draft that says that user agents MUST be able to deal with 
> multiple
> > > SDP
> > > > bodies if they request Session: QoS?
> > > >
> > > >
> > > > Last question/issue:
> > > > If peers include a key (and crypto algorithm, key length, etc.) in the
> > > > session description (for example, using a k= tag in SDP), instead 
> of later
> > > > using IKE to establish an SA, do they include "Session: Security"?
> > > >
> > > > thanks,
> > > > -rohan
> > > >
> > > >
> >
> >




From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 21 22:53:54 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01216
	for ; Tue, 21 Mar 2000 22:53:53 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id C0C4652B6; Tue, 21 Mar 2000 22:51:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 41F9852D4; Tue, 21 Mar 2000 22:51:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 93AE152B6
	for ; Tue, 21 Mar 2000 22:51:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 21 22:49:11 EST 2000
Received: from smtp-out1.bellatlantic.net ([199.45.39.156]) by dusty; Tue Mar 21 22:49:10 EST 2000
Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id WAA22938
	for ; Tue, 21 Mar 2000 22:48:55 -0500 (EST)
Message-ID: <38D842C3.41B1213A@cs.columbia.edu>
Date: Tue, 21 Mar 2000 22:49:23 -0500
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: SIP server DHCP option
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

The last-call for the SIP DHCP option ended a few days ago. As far as I
can tell, there have been no technical comments regarding the DHCP SIP
option on the DHCP. The draft was also discussed on the namedroppers
list (for DNS issues). There, Robert Elz suggested to drop the "fake"
SRV option (listing servers, weights, etc.) and suggested a few
clarifications (such as format of the DNS name and error behavior).

Gautam and I are not particularly attached to the "fake SRV" option, so
we'd be happy to drop it and strongly encourage people to implement SRV,
so that there's one rather than two mechanisms for server selection.
However, if others are fond of the option, we'd like to hear about it.

We will make the suggested clarifications and submit another version
after Adelaide. Please let me know if I inadvertently missed any
comments.

Thanks.

Henning



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 00:23:55 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09096
	for ; Wed, 22 Mar 2000 00:23:55 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 932BB52C4; Wed, 22 Mar 2000 00:18:08 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 90EE452D4; Wed, 22 Mar 2000 00:18:07 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id CC5EF52C4
	for ; Wed, 22 Mar 2000 00:17:09 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 00:17:01 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed Mar 22 00:16:59 EST 2000
Received: from dynamicsoft.com (1Cust14.tnt3.freehold.nj.da.uu.net [63.25.172.14])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA06524;
	Wed, 22 Mar 2000 00:18:05 -0500 (EST)
Message-ID: <38D858E9.2DA6CF95@dynamicsoft.com>
Date: Wed, 22 Mar 2000 00:23:53 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rohan Mahy 
Cc: William Marshall , sip@lists.research.bell-labs.com
Subject: Re: clarifications on 183 and "manyfolks" drafts
References: <4.2.0.58.20000321110328.00be9240@lint.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Rohan Mahy wrote:
> 
> Hi,
> 
> OK, I get the need for preconditions. 

I am in agreement with Bill's assessment here. The idea is to keep the
precondition mechanism independent of the underlying QoS protocol.

However, I disagree that the Session header only makes sense for 183. I
see no reason why. My view of the Session header is that it informs the
UA that there is some dependency on signaling behavior because of the
session. The QoS and security Session: tokens in a request indicate that
the INVITE should not cause local alerting until the preconditions are
met, and that a provisional response with SDP should be sent. The QoS 
and security Session: in the provisional response indicates a similar
thing - don't do anything with this message until the preconditions are
met. So, I would argue its OK to put a Session header in a 180, in which
case ringing (signaled by 180) doesn't occur until the preconditions are
met.


 We still need to get session
> descriptions from B,C, and D to A.  My proposal was sending these in one
> 183 with multiple bodies.  Is this reasonable?

No, it is not. In a previous note, you wrote:

> >If the proxy forks the request to three endpoints, each of those endpoints
> >will send a 183-Session-Progress back to A, each including one SDP for
> >the media stream to them.  These are presumably distinguished by a tag
> >field in the call-leg identification.  A has the job of managing three
> >separate QoS reservations (or one reservation that can be used for three
> >destinations), depending on the interfaces it has available.  In general, I'd
> >expect three separate PRECONDITION-MET messages, one each to B, C, and D,
> >with the success/failure results for each.  No additional work for the proxy.
> 
> While this approach might work for a stateless proxy, I'm interested in the 
> behavior of a stateful, parallel, forking proxy.  The behavior you 
> described would be illegal (forwarding off the Via list) in this kind of 
> proxy, since the INVITEs to B, C, & D would be sourced from the proxy, 
> which would be the last stop on the Via list of each forked INVITE.  A 
> would never see any responses to the proxy's forked INVITEs.
> 

This is not correct. The INVITE is originated at A. When the proxy
forks, it does not re-originate the request. It will add a Via header,
different for each forked request in the branch-id parameter. Thus, the
three provisional responses can all be distinguished at the proxy. The
proxy should forward all three upstream, even if its stateful. In fact,
since the proxy forked, its not allowed to be stateless. The UAC will be
able to distinguish the provisional responses by tag in the To field.

A proxy should definitely not try to aggregate bodies from multiple
provisional responses. There are numerous problems with doing so, not
the least of which is invalidating signatures, mandating MIME multipart,
processing burden on the proxy, latency for sending a provisional
response (you must wait for all of them), and so on. 

You also wrote:
> > If peers include a key (and crypto algorithm, key length, etc.) in the
> > session description (for example, using a k= tag in SDP), instead of later
> > using IKE to establish an SA, do they include "Session: Security"?
>

Including a k= tag in SDP is probably not the best way to establish a SA
for the media session. It is completely insecure unless the SIP message
is encrypted, and there are some issues with blind encryption of SIP
messages before the called parties identity is known. The security task
force is considering the right approach for this.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 01:01:56 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24637
	for ; Wed, 22 Mar 2000 01:01:56 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id AB9D252B6; Wed, 22 Mar 2000 00:59:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 21F6B52D5; Wed, 22 Mar 2000 00:59:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 3352E52B6
	for ; Wed, 22 Mar 2000 00:59:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 00:58:52 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed Mar 22 00:58:51 EST 2000
Received: from dynamicsoft.com (1Cust14.tnt3.freehold.nj.da.uu.net [63.25.172.14])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA06571;
	Wed, 22 Mar 2000 00:59:58 -0500 (EST)
Message-ID: <38D862B9.1BE71FC7@dynamicsoft.com>
Date: Wed, 22 Mar 2000 01:05:45 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert.Sparks@wcom.com
Cc: "'Li Li'" , sip@lists.research.bell-labs.com
Subject: Re: Comments on transfer draft (sparks-sip-cc-transfer-00)
References: <003201bf9354$0f919bc0$999923a6@mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

A few additional clarifications:

Robert Sparks wrote:
> 
> Allowing the media relationship between the transferee
> and the transferor to be handled outside of the TRANSFER
> transaction gives us the greatest flexibility. The examples
> I gave showed terminating streams with holds, but other
> scenarios may be appropriate depending on the capabilities
> of the UA.
> 
> RjS
> 
> > -----Original Message-----
> > From: Li Li [mailto:lili@ss8networks.com]
> > Sent: Tuesday, March 21, 2000 9:39 AM
> > To: Robert.Sparks@wcom.com
> > Cc: jdrosen@dynamicsoft.com; sip@lists.research.bell-labs.com
> > Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)
> >
> >
> > Just a very simple question on the transfer flows in
> > the draft. Sorry for my limited understanding of this feature.
> > But is the reason for the INVITE(hold) from the transferor
> > to the transferee just to tell him to hold (taking care of
> > the media path) and wait for a TRANSFER request (or later may
> > be some other requests) to follow?

Hold does not also indicate that the far side should wait for a
transfer. Its just a good way to smoothly hand off the media streams. 

 So if the TRANSFER doesn't
> > follow, what should be the behavior?

No different than if someone puts you on hold and never takes you off.
The hold is completely independent of the transfer.


 Can we do without the
> > INVITE(hold) message but just to use the TRANSFER with a (hold)
> > to achieve the same thing?

You can't do transfer and hold atomically with one message. Thats
because the new TRANSFER method specifically doesn't carry a body such
as SDP. It is not meant to modifymedia session state. Using a single
method to convey multiple different semantics gets complicated, and this
was the whole difficulty with the BYE/Also in the first place.


 The transferee can respond to this
> > TRANSFFER request to refuse the transfer. Or a 100 trying
> > response tells the transferor he agrees to transfer and
> > starts trying and holding the media path. The 200 OK response
> > for the TRANSFER then tells the transferor that the transfer
> > is successful. My two cents only. Correct me if I'm wrong.

You are again running into the same issues with BYE/ALso. You are trying
to place two behaviors into one method, so generating responses is hard.
I don't think doing this is a the best approach.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 01:15:56 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01199
	for ; Wed, 22 Mar 2000 01:15:55 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 5A04952D5; Wed, 22 Mar 2000 01:13:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id ABC6752DA; Wed, 22 Mar 2000 01:13:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 8490952D5
	for ; Wed, 22 Mar 2000 01:13:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 01:12:46 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed Mar 22 01:12:46 EST 2000
Received: from dynamicsoft.com (1Cust14.tnt3.freehold.nj.da.uu.net [63.25.172.14])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA06580;
	Wed, 22 Mar 2000 01:13:54 -0500 (EST)
Message-ID: <38D865FE.682E4796@dynamicsoft.com>
Date: Wed, 22 Mar 2000 01:19:42 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Li 
Cc: sip@lists.research.bell-labs.com, schulzrinne@cs.columbia.edu
Subject: Re: comments on draft-rosenberg-sip-3pcc-00.txt
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Li Li wrote:
> 
> Indeed a very good and very useful feature.
> One question just for clarification.
> 
> When the controller sends the separate INVITE's
> to the parties to be involved in the call, what
> should be used in the from, to and call-id headers
> to form the call leg? The two INVITE's may have
> the same call leg, which means the caler and callee
> may not know there's a controller involved.

Whilst this would be nice, I have concerns that this will break every
security capability. Basically, the controller would be lying about its
identity.

The Call-ID for each of the two INVITEs can be different. The To fields
will also be different, reflecting the two addresses being contacted.
The From field will probably need to contain an identifier for the
controller.

> The
> caller and callee cannot send other requests for the
> call directly to each other without going through
> the controller? (not so good in some of the cases.)

No, they can't. Each participant doesn't know about the other from a SIP
perspective. Each believes its talking to the controller. Neither has
even an address for the other for SIP (they do have each others media
addresses). 

There is no reasonable way, as far as I can tell, to allow the two
parties to signal each other directly in the model presented in the
document. The idea is that many services require some central point to
know everything thats going on, and to independently control all parties
in the call. The mechanism achieves that. Its not meant to handle other
models of third party call control. Things like pint present alternative
models with their own pros and cons.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 01:29:57 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08173
	for ; Wed, 22 Mar 2000 01:29:56 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 5EEDB52DA; Wed, 22 Mar 2000 01:27:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id CE9D852DB; Wed, 22 Mar 2000 01:27:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id AEE3F52DA
	for ; Wed, 22 Mar 2000 01:27:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 01:26:29 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed Mar 22 01:26:29 EST 2000
Received: from dynamicsoft.com (1Cust14.tnt3.freehold.nj.da.uu.net [63.25.172.14])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA06605
	for ; Wed, 22 Mar 2000 01:27:38 -0500 (EST)
Message-ID: <38D86936.29B97A5B@dynamicsoft.com>
Date: Wed, 22 Mar 2000 01:33:26 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: Meeting of the SIP Security Task Force
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Folks,

The SIP Security Task Force will be having a meeting in Adelaide on the
Sunday before IETF. We'll be meeting in the lobby of the Stamford Plaza
Adelaide (150 North Terrace) at 10am, and hopefully work in the lobby
unless we get thrown out ;). I hope to work till around 2ish. As with
all design teams, the meeting is open to all. Please let me know if you
will be coming. Note that minutes will be made available, so folks who
just want to listen can have fun sightseeing instead and read the
minutes later ;)

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 01:59:51 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21782
	for ; Wed, 22 Mar 2000 01:59:51 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id E486252D4; Wed, 22 Mar 2000 01:57:21 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 62B3452DD; Wed, 22 Mar 2000 01:57:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 45BF652D4
	for ; Wed, 22 Mar 2000 01:57:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 22 01:55:06 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed Mar 22 01:55:05 EST 2000
Received: from dynamicsoft.com (1Cust14.tnt3.freehold.nj.da.uu.net [63.25.172.14])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA06678;
	Wed, 22 Mar 2000 01:56:13 -0500 (EST)
Message-ID: <38D86FE8.CFD1CEF3@dynamicsoft.com>
Date: Wed, 22 Mar 2000 02:02:00 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert.Sparks@wcom.com
Cc: "'Henning Schulzrinne'" ,
        sip@lists.research.bell-labs.com
Subject: Re: Comments on transfer draft (sparks-sip-cc-transfer-00)
References: <005201bf92ae$54c49f40$999923a6@mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Robert Sparks wrote:
> 
> I am hesitant to integrate a new mechanism for proving the identity
> of the transferor, or even reuse the pgp signature approach of
> sip-cc-01 if someone is working an infrastructure that should be used
> instead. In any case, such a function should be generalized beyond
> just this method, so, again, I am hesitant to place its definition
> directly in this draft. Is this thinking way off base?

Not sure. Its worth discussing at the security design team meeting.

> > The presence of a body should not, in any way, alter the
> > basic semantics
> > of the request. Treatment of a body in TRANSFER is no different than
> > bodies in any other request. If the UAS doesn't know what to
> > do with it,
> > it sends a 415. If it does know what to do with  it, it gets
> > processed.
> 
> In those cases where the side-effect of processing the body doesn't
> affect the processing of the method (like displaying an optional
> visual thumb of the caller), I agree. I have no problem changing
> the wording of the draft to allow that kind of body part. However,
> if you give meaning to the body parts in the context of processing the
> message (such as we have right now with application/sdp - the presence
> or absence of that body part affects the state of a receiving SIP engine),

SDP doesn't affect the processing of the SIP engine, only the component
thats handling the media session. In general, a body should not change
the basic semantic of the request. If a UAS doesn't know what to do with
a body in a particular request, it should reject it.

> > > Are you suggesting the subsequent invite look like this?
> > >
> > > INVITE sip:transfer-target@targethost?Call-ID=abc@eeOrorhost
> > > Call-ID: def@eehost
> >
> > No, like this:
> >
> > INVITE sip:transfer-target@targethost
> > Call-ID: abc@ee0rorhost
> >
> > This way, the tranferror could ask the transferred party to add other
> > headers or even body elements.
> >
> 
> OK - I can see this for the other headers and body-elements, but for
> Call-ID itself, are you not just adding redundant information to the
> message? If its already in the Call-ID header in the request, how does
> it help to have it also in the Request-URI? (My apologies if I'm being
> dense).

Your not being dense. Its just to avoid special casing the Call-ID. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 02:20:01 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05861
	for ; Wed, 22 Mar 2000 02:20:01 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 9D49A52DD; Wed, 22 Mar 2000 02:17:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 1E32B52DE; Wed, 22 Mar 2000 02:17:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 9EC1F52DD
	for ; Wed, 22 Mar 2000 02:17:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 02:15:27 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Wed Mar 22 02:15:26 EST 2000
Received: from dynamicsoft.com (1Cust14.tnt3.freehold.nj.da.uu.net [63.25.172.14])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA06706;
	Wed, 22 Mar 2000 02:12:38 -0500 (EST)
Message-ID: <38D873C1.D2797AA7@dynamicsoft.com>
Date: Wed, 22 Mar 2000 02:18:25 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen 
Cc: SIP 
Subject: Re: Session timer comments
References: <38CCEB34.E5CE4B41@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Anders Kristensen wrote:
> 
> A couple of comments on the session timer draft...
> 
> The first is that I think it would be better if timer refreshing used a
> method other than INVITE, say TIMER-REFRESH. There are several drawbacks
> to reusing INVITE:
> 
>   o UAC must send a superfluous ACK for timer refresh responses
>   o timer refresh INVITEs must carry a body which has no use
>     whatsoever
>   o overloading INVITE makes logic in UAS more complex
>   o UAS may respond with non-200 which really doesn't make
>     sense for timer refresh

I'm not sure I agree with this. As a general rule, protocols which have
refreshes use the same message for refresh as the original thing. I
agree ACK is superflous, but I think its good to stick with this model.
If a non-200 response comes to a re-INVITE refresh, it makes perfect
sense. Its the same thing as when a re-INVITE that changes session
parameters is rejected.

I don't consider this overloading re-INVITEs; yes, there is additional
logic to process the timer, but thats the case for any header in a
request. Overloading is when the header makes the meaning of the method
something different. I don't think thats the case here.


> 
> Secondly, on the open issues
> 
>    o Should we allow the UAC to insert a Require header in the
>      request, indicating that the UAS must support the session
>      timer?  (I think no)
> 
> This is allowed as per the definition of extensions and the Require
> header. Why would you go out of your way to disallow it in this case?

Hmm, I suppose you're right. OK, we can allow them.


> 
>    o With this draft (and the previous versions), there was no way
>      for the proxy to reject the call if the calling UA supported
>      the session timer, but the called UA didn't. Is this a
>      problem? If so, what can be done about it? (I think there is
>      nothing we can do, and we should not worry about it)
> 
> This seems to me to be a big problem. It means there are circumstances
> under which a call-statefull proxy *cannot* protect itself against DoS
> attacks. It *must* allow the session to proceed without timers.
> 
> Fortunately there may be a simple solution: when a UAC sends an INVITE
> through a proxy indicating that it supports the 'timer' extension but
> without either "Require: timer" and "Session-Expires:" headers the proxy
> inserts a "Require: timer" before forwarding the INVITE:

Interesting idea. It might work. A few issues:

1. If the request is signed, and the Require header is below the
Authorization header, the proxy can't muck with it. 
2. The UAC is going to be confused. It sent a request without a Require
header, and gets a 420 listing some random extension as being
Unsupported. What does it do then? 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 07:06:23 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17584
	for ; Wed, 22 Mar 2000 07:06:23 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 064E252B6; Wed, 22 Mar 2000 07:03:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 723FF52D4; Wed, 22 Mar 2000 07:03:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 7154A52B6
	for ; Wed, 22 Mar 2000 07:03:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 07:02:37 EST 2000
Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Wed Mar 22 07:02:36 EST 2000
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel3.hp.com (Postfix) with ESMTP
	id C686A1B02; Wed, 22 Mar 2000 04:02:34 -0800 (PST)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA06013;
	Wed, 22 Mar 2000 12:02:33 GMT
Message-ID: <38D8B67C.E4A14A16@hplb.hpl.hp.com>
Date: Wed, 22 Mar 2000 12:03:08 +0000
From: Anders Kristensen 
Organization: HP Labs
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: SIP 
Subject: Re: Session timer comments
References: <38CCEB34.E5CE4B41@hplb.hpl.hp.com> <38D873C1.D2797AA7@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Jonathan Rosenberg wrote:
> 
> Anders Kristensen wrote:
> >
> > A couple of comments on the session timer draft...
> >
> > The first is that I think it would be better if timer refreshing used a
> > method other than INVITE, say TIMER-REFRESH. There are several drawbacks
> > to reusing INVITE:
> >
> >   o UAC must send a superfluous ACK for timer refresh responses
> >   o timer refresh INVITEs must carry a body which has no use
> >     whatsoever
> >   o overloading INVITE makes logic in UAS more complex
> >   o UAS may respond with non-200 which really doesn't make
> >     sense for timer refresh
> 
> I'm not sure I agree with this. As a general rule, protocols which have
> refreshes use the same message for refresh as the original thing. I
> agree ACK is superflous, but I think its good to stick with this model.
> If a non-200 response comes to a re-INVITE refresh, it makes perfect
> sense. Its the same thing as when a re-INVITE that changes session
> parameters is rejected.

A non-200 status makes sense in responses to "traditional" re-INVITEs
whose purpose it is to modify the media streams, but I don't see what
purpose a non-200 response could possibly have for re-INVITEs whose sole
purpose it is to refresh the session timer. Are you saying refreshing
the session timer can fail?

> 
> I don't consider this overloading re-INVITEs; yes, there is additional
> logic to process the timer, but thats the case for any header in a
> request. Overloading is when the header makes the meaning of the method
> something different. I don't think thats the case here.

I would say overloading occurs when the same mechanism is used for
separate and independent purposes. In this case re-INVITEs are used for
modifying media streams and for refreshing session timer.

I still think we'd be better off with a new method, but if I'm the only
one I'll shut up about it.

> 
> >
> > Secondly, on the open issues
> >
> >    o Should we allow the UAC to insert a Require header in the
> >      request, indicating that the UAS must support the session
> >      timer?  (I think no)
> >
> > This is allowed as per the definition of extensions and the Require
> > header. Why would you go out of your way to disallow it in this case?
> 
> Hmm, I suppose you're right. OK, we can allow them.
> 
> >
> >    o With this draft (and the previous versions), there was no way
> >      for the proxy to reject the call if the calling UA supported
> >      the session timer, but the called UA didn't. Is this a
> >      problem? If so, what can be done about it? (I think there is
> >      nothing we can do, and we should not worry about it)
> >
> > This seems to me to be a big problem. It means there are circumstances
> > under which a call-statefull proxy *cannot* protect itself against DoS
> > attacks. It *must* allow the session to proceed without timers.
> >
> > Fortunately there may be a simple solution: when a UAC sends an INVITE
> > through a proxy indicating that it supports the 'timer' extension but
> > without either "Require: timer" and "Session-Expires:" headers the proxy
> > inserts a "Require: timer" before forwarding the INVITE:
> 
> Interesting idea. It might work. A few issues:
> 
> 1. If the request is signed, and the Require header is below the
> Authorization header, the proxy can't muck with it.

Right, but in this case I suppose adding another Require header above
the Authorization header wont hurt.

> 2. The UAC is going to be confused. It sent a request without a Require
> header, and gets a 420 listing some random extension as being
> Unsupported. What does it do then?

The draft would mandate that the UAC treat this case as if it had itself
required the 'timer' extension in the first case, i.e. the INVITE fails
as it should do.  This is not to say that requests in general can fail
with 420 for extensions they didn't Require. The draft would allow it
specifically for the case where a UAC sends an INVITE indicating
"Supported: timer" without "Require: timer". Like I said in the original
posting I believe this is acceptable because its basically a matter of
definition. If a UA supports the 'timer' extension it is required to
understand this special case.

Anders

-- 
Anders Kristensen ,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 09:56:03 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16105
	for ; Wed, 22 Mar 2000 09:56:02 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id AAF4D52B6; Wed, 22 Mar 2000 09:53:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 1908952C4; Wed, 22 Mar 2000 09:53:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 31E3552B6
	for ; Wed, 22 Mar 2000 09:53:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 09:51:48 EST 2000
Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Mar 22 09:51:46 EST 2000
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA24850;
	Wed, 22 Mar 2000 09:47:46 -0500 (EST)
Message-ID: <38D8DD11.1809CF54@cs.columbia.edu>
Date: Wed, 22 Mar 2000 09:47:45 -0500
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen 
Cc: Jonathan Rosenberg ,
        SIP 
Subject: Re: Session timer comments
References: <38CCEB34.E5CE4B41@hplb.hpl.hp.com> <38D873C1.D2797AA7@dynamicsoft.com> <38D8B67C.E4A14A16@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Anders Kristensen wrote:
> 

> 
> A non-200 status makes sense in responses to "traditional" re-INVITEs
> whose purpose it is to modify the media streams, but I don't see what
> purpose a non-200 response could possibly have for re-INVITEs whose sole
> purpose it is to refresh the session timer. Are you saying refreshing
> the session timer can fail?

While not likely, this is possible. Imagine that the UAS crashes and
then comes back to life, minus recollection of call-id in the timer
refresh. In that case, a failure is quite likely. (The resurrected UAS
would treat it as a new call, which would be appropriate, but the user
might refuse the new call or something else might go wrong.)


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 10:14:02 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22665
	for ; Wed, 22 Mar 2000 10:14:01 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id BD55152C4; Wed, 22 Mar 2000 10:11:21 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 3B80852D4; Wed, 22 Mar 2000 10:11:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 0526052C4
	for ; Wed, 22 Mar 2000 10:11:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 10:11:02 EST 2000
Received: from palrel1.hp.com ([156.153.255.242]) by dusty; Wed Mar 22 10:11:01 EST 2000
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by palrel1.hp.com (Postfix) with ESMTP
	id 132065A8; Wed, 22 Mar 2000 07:10:59 -0800 (PST)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id PAA17352;
	Wed, 22 Mar 2000 15:10:57 GMT
Message-ID: <38D8E2A4.FD004D4C@hplb.hpl.hp.com>
Date: Wed, 22 Mar 2000 15:11:32 +0000
From: Anders Kristensen 
Organization: HP Labs
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne 
Cc: Jonathan Rosenberg ,
        SIP 
Subject: Re: Session timer comments
References: <38CCEB34.E5CE4B41@hplb.hpl.hp.com> <38D873C1.D2797AA7@dynamicsoft.com> <38D8B67C.E4A14A16@hplb.hpl.hp.com> <38D8DD11.1809CF54@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Henning Schulzrinne wrote:
> 
> Anders Kristensen wrote:
> >
> > A non-200 status makes sense in responses to "traditional" re-INVITEs
> > whose purpose it is to modify the media streams, but I don't see what
> > purpose a non-200 response could possibly have for re-INVITEs whose sole
> > purpose it is to refresh the session timer. Are you saying refreshing
> > the session timer can fail?
> 
> While not likely, this is possible. Imagine that the UAS crashes and
> then comes back to life, minus recollection of call-id in the timer
> refresh. In that case, a failure is quite likely. (The resurrected UAS
> would treat it as a new call, which would be appropriate, but the user
> might refuse the new call or something else might go wrong.)

Excellent point, but isn't this just another argument for using a
non-INVITE method? In this case, by using INVITE the timer refresh
operation might be interpreted as a regular, brand new INVITE, whereas
with a non-INVITE method the refresh would correctly be recognized as
belonging to an "old" call and would be rejected with a 481 just like,
say, a BYE received for an old call after a UAS comes back up after a
crash.

Anders

-- 
Anders Kristensen ,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 10:48:02 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04825
	for ; Wed, 22 Mar 2000 10:48:02 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 0C7E752BB; Wed, 22 Mar 2000 10:45:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8298952D4; Wed, 22 Mar 2000 10:45:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 847C852BB
	for ; Wed, 22 Mar 2000 10:45:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 10:44:47 EST 2000
Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Wed Mar 22 10:44:46 EST 2000
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FRT003DBYEKPO@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Wed, 22 Mar 2000 15:44:44 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with ESMTP id <0FRT00I01YEJC9@pmismtp02.wcomnet.com>;
 Wed, 22 Mar 2000 15:44:44 +0000 (GMT)
Received: from omta4.mcit.com ([166.37.204.6])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0FRT00FFXYEHW4@pmismtp02.wcomnet.com>; Wed,
 22 Mar 2000 15:44:43 +0000 (GMT)
Received: from sipdev4 ([166.35.153.153])
 by omta4.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000322153952.JIX470@sipdev4>; Wed, 22 Mar 2000 15:39:52 +0000
Date: Wed, 22 Mar 2000 09:30:40 -0600
From: Robert Sparks 
Subject: RE: Comments on transfer draft (sparks-sip-cc-transfer-00)
In-reply-to: <38D86FE8.CFD1CEF3@dynamicsoft.com>
To: "'Jonathan Rosenberg'" 
Cc: "'Henning Schulzrinne'" ,
        sip@lists.research.bell-labs.com
Reply-To: Robert.Sparks@wcom.com
Message-id: <002c01bf9413$955490e0$999923a6@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> SDP doesn't affect the processing of the SIP engine, only the 
> component
> thats handling the media session. In general, a body should not change
> the basic semantic of the request. If a UAS doesn't know what 
> to do with
> a body in a particular request, it should reject it.

The contents of the SDP body may not affect the processing 
in the SIP engine (past the inclusion of warning headers and
maybe choosing a different response code if it fails to parse),
but the presence/absence of the body in the INVITE request does. 

                            |
INVITE   200 OK     ACK     vs   INVITE    200 OK   ACK
SDP      SDP        noSDP   |    noSDP     SDP      SDP

RjS



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 11:30:04 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20103
	for ; Wed, 22 Mar 2000 11:30:04 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id E284352BB; Wed, 22 Mar 2000 11:27:21 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6715252D4; Wed, 22 Mar 2000 11:27:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 94EFC52BB
	for ; Wed, 22 Mar 2000 11:27:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 22 11:25:57 EST 2000
Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Wed Mar 22 11:25:56 EST 2000
Received: from cisco.com (bounty.cisco.com [161.44.2.72])
	by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id LAA10175;
	Wed, 22 Mar 2000 11:25:54 -0500 (EST)
Message-ID: <38D8F412.D44AC41A@cisco.com>
Date: Wed, 22 Mar 2000 11:25:54 -0500
From: Shail Bhatnagar 
Organization: CISCO
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: SIP IETF 
Subject: Stateful Proxies : 32 Seconds Window ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I quote 2543bis :

"A stateful proxy SHOULD NOT become stateless until after it sends a definitive
response upstream, and at least 32 seconds after it received a definitive
response."

Does this mean that a stateful proxy can become stateless after receiving 
the ACK for a final response that it generated ??

I think for non-INVITE requests - the spec says maintain state for atleast
10*T2 or 40 seconds after sending a final response upstream.



-- 
Best regards,
Shail



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 14:56:13 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05479
	for ; Wed, 22 Mar 2000 14:56:12 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 96C1652C4; Wed, 22 Mar 2000 14:53:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 1244352D4; Wed, 22 Mar 2000 14:53:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 49BC752C4
	for ; Wed, 22 Mar 2000 14:53:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 22 14:52:58 EST 2000
Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Wed Mar 22 14:52:57 EST 2000
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FRU00J8Y9W8L5@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Wed, 22 Mar 2000 19:52:56 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with ESMTP id <0FRU006019W7W9@dgismtp02.wcomnet.com> for
 sip@lists.research.bell-labs.com; Wed, 22 Mar 2000 19:52:56 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0FRU003LR9W7QG@dgismtp02.wcomnet.com> for
 sip@lists.research.bell-labs.com; Wed, 22 Mar 2000 19:52:55 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2571.0)
	id ; Wed, 22 Mar 2000 19:52:55 +0000
Content-return: allowed
Date: Wed, 22 Mar 2000 19:52:53 +0000
From: "Donovan, Steven R." 
Subject: Comment on draft-ietf-sip-isup-mime-00.txt
To: sip@lists.research.bell-labs.com
Message-id: <75C79E507864D3118AFC00805FEAB7D8349381@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: text/plain; charset=ISO-8859-1
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

One quick comment on the security section of this draft.  I agree that it is
true that the security section in SIP that discusses end-to-end encryption
of the SIP message body should be sufficient to meet the security concerns
associated with carrying ISUP and QSIG message bodies.

I would, however, suggest that the following be added to the spec:

"Due to the potentially sensitive nature of the information contained in
ISUP and QSIG message bodies, the UAC SHOULD perform end-to-end encryption
on ISUP and QSIG message bodies."

This will prevent the message bodies from being interpretted when the SIP
message is intercepted or is routed to non MGC based user agents that will
normally display (or attempt to display) the message body to an end user.
It would generally not be good to have a calling number made available when
it is explicitly marked for no presentation.

Steve



From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 20:42:12 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09998
	for ; Wed, 22 Mar 2000 20:42:10 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 7460452BB; Wed, 22 Mar 2000 20:39:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id E45B952D4; Wed, 22 Mar 2000 20:39:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id E780A52BB
	for ; Wed, 22 Mar 2000 20:39:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 20:38:28 EST 2000
Received: from diablo.cisco.com ([171.68.224.210]) by dusty; Wed Mar 22 20:38:28 EST 2000
Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id RAA08223; Wed, 22 Mar 2000 17:38:21 -0800 (PST)
Message-Id: <4.1.20000322193628.00bba860@diablo.cisco.com>
X-Sender: jmpolk@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 22 Mar 2000 19:36:51 -0600
To: Jonathan Rosenberg ,
        sip@lists.research.bell-labs.com
From: "James M. Polk" 
Subject: Re: Meeting of the SIP Security Task Force
In-Reply-To: <38D86936.29B97A5B@dynamicsoft.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_1785006==_.ALT"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

--=====================_1785006==_.ALT
Content-Type: text/plain; charset="us-ascii"


Jonathan

I'll be there

Thanks!

At 01:33 AM 3/22/2000 -0500, Jonathan Rosenberg wrote:
>Folks,
>
>The SIP Security Task Force will be having a meeting in Adelaide on the
>Sunday before IETF. We'll be meeting in the lobby of the Stamford Plaza
>Adelaide (150 North Terrace) at 10am, and hopefully work in the lobby
>unless we get thrown out ;). I hope to work till around 2ish. As with
>all design teams, the meeting is open to all. Please let me know if you
>will be coming. Note that minutes will be made available, so folks who
>just want to listen can have fun sightseeing instead and read the
>minutes later ;)
>
>-Jonathan R.
>-- 
>Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
>http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
>http://www.dynamicsoft.com
>
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com
--=====================_1785006==_.ALT
Content-Type: text/html; charset="us-ascii"


Jonathan




I'll be there




Thanks!




At 01:33 AM 3/22/2000 -0500, Jonathan Rosenberg wrote:


>Folks,


>


>The SIP Security Task Force will be having a meeting in Adelaide
on the


>Sunday before IETF. We'll be meeting in the lobby of the
Stamford Plaza


>Adelaide (150 North Terrace) at 10am, and hopefully work in the
lobby


>unless we get thrown out ;). I hope to work till around 2ish. As
with


>all design teams, the meeting is open to all. Please let me know
if you


>will be coming. Note that minutes will be made available, so
folks who


>just want to listen can have fun sightseeing instead and read
the


>minutes later ;)


>


>-Jonathan R.


>-- 


>Jonathan D.
Rosenberg                      
72 Eagle Rock Ave.


>Chief
Scientist                            
First Floor


>dynamicsoft                                
East Hanover, NJ 07936


>jdrosen@dynamicsoft.com                    
FAX:   (732) 741-4778


>http://www.cs.columbia.edu/~jdrosen        
PHONE: (732) 741-7244



>


>






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

"At the end of the day... the most committed win!"





James M. Polk

Sr. Product Manager, Multiservice Architecture and Standards

Enterprise Voice Business Unit

Cisco Systems

Dallas, Texas

w) 972.813.5208

f)  972.813.5280

www.cisco.com

--=====================_1785006==_.ALT--




From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 21:07:54 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19741
	for ; Wed, 22 Mar 2000 21:07:52 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 813DB52D4; Wed, 22 Mar 2000 21:05:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 0B8AF52D5; Wed, 22 Mar 2000 21:05:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 9DC3F52D4
	for ; Wed, 22 Mar 2000 21:05:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 22 21:03:05 EST 2000
Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Wed Mar 22 21:03:04 EST 2000
Received: from vovida.com (pool0782.cvx20-bradley.dialup.earthlink.net [209.179.253.17])
	by repulse.cnchost.com
	id VAA07500; Wed, 22 Mar 2000 21:02:55 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38D9980E.C31694FA@vovida.com>
Date: Wed, 22 Mar 2000 20:05:34 -0800
From: Krishan Veer 
Organization: Vovida Networks
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: Reg SIPURL:
Content-Type: multipart/alternative;
 boundary="------------8A726B83903ECA6B549F5E7B"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


--------------8A726B83903ECA6B549F5E7B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi !

My query  is in context of  : is "tag" part of URL -parameters ? , if we
look at the specs in rfc2543 on SIP-URL Syntax (figure 3),
"url-parameter = transport-parm | user-parm | method-param | ttl-param|
maddr-param | other-param "
it says nothing about "tag" though "tag" is field there !!!. Should we
include tag in URLparameter or other-param.?.

thanks  ; )

--
Krishan veer
Software Engineer
http://www.vovida.com
"Fueling the Communications Revolution"



--------------8A726B83903ECA6B549F5E7B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi !

My query  is in context of  : is "tag" part of URL -parameters
? , if we look at the specs in rfc2543 on SIP-URL Syntax (figure 3),

"url-parameter = transport-parm | user-parm | method-param | ttl-param|
maddr-param | other-param "

it says nothing about "tag" though "tag" is field there !!!. Should
we include tag in URLparameter or other-param.?.

thanks  ; )

-- 
Krishan veer
Software Engineer
http://www.vovida.com
"Fueling the Communications Revolution"

 

--------------8A726B83903ECA6B549F5E7B--




From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 22:27:55 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20745
	for ; Wed, 22 Mar 2000 22:27:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 50E8752B6; Wed, 22 Mar 2000 22:25:21 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id C149052DA; Wed, 22 Mar 2000 22:25:20 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 51D0552B6
	for ; Wed, 22 Mar 2000 22:25:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 22 22:23:14 EST 2000
Received: from kickme.cisco.com ([198.92.30.42]) by dusty; Wed Mar 22 22:23:13 EST 2000
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id TAA15518;
	Wed, 22 Mar 2000 19:10:20 -0800 (PST)
Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122])
	by imop.cisco.com (Mirapoint)
	with ESMTP id ABT01178;
	Wed, 22 Mar 2000 19:21:28 -0800 (PST)
Message-Id: <4.2.0.58.20000322095125.00c4c830@lint.cisco.com>
X-Sender: rmahy@imop.cisco.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 22 Mar 2000 19:22:32 -0800
To: Jonathan Rosenberg 
From: Rohan Mahy 
Subject: Re: clarifications on 183 and "manyfolks" drafts
Cc: William Marshall , sip@lists.research.bell-labs.com
In-Reply-To: <38D858E9.2DA6CF95@dynamicsoft.com>
References: <4.2.0.58.20000321110328.00be9240@lint.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

At 09:23 PM 3/21/00 , Jonathan Rosenberg wrote:
>Rohan Mahy wrote:
> > OK, I get the need for preconditions.
>
>I am in agreement with Bill's assessment here. The idea is to keep the
>precondition mechanism independent of the underlying QoS protocol.
>
>However, I disagree that the Session header only makes sense for 183. I
>see no reason why. My view of the Session header is that it informs the
>UA that there is some dependency on signaling behavior because of the
>session. The QoS and security Session: tokens in a request indicate that
>the INVITE should not cause local alerting until the preconditions are
>met, and that a provisional response with SDP should be sent. The QoS
>and security Session: in the provisional response indicates a similar
>thing - don't do anything with this message until the preconditions are
>met. So, I would argue its OK to put a Session header in a 180, in which
>case ringing (signaled by 180) doesn't occur until the preconditions are
>met.

great.  this could save a whole cycle of 183/ PRACK/ 200 messages in some 
circumstances.

>  We still need to get session
> > descriptions from B,C, and D to A.  My proposal was sending these in one
> > 183 with multiple bodies.  Is this reasonable?
>
>No, it is not. In a previous note, you wrote:
>
> > >If the proxy forks the request to three endpoints, each of those endpoints
> > >will send a 183-Session-Progress back to A, each including one SDP for
> > >the media stream to them.  These are presumably distinguished by a tag
> > >field in the call-leg identification.  A has the job of managing three
> > >separate QoS reservations (or one reservation that can be used for three
> > >destinations), depending on the interfaces it has available.  In 
> general, I'd
> > >expect three separate PRECONDITION-MET messages, one each to B, C, and D,
> > >with the success/failure results for each.  No additional work for the 
> proxy.
> >
> > While this approach might work for a stateless proxy, I'm interested in 
> the
> > behavior of a stateful, parallel, forking proxy.  The behavior you
> > described would be illegal (forwarding off the Via list) in this kind of
> > proxy, since the INVITEs to B, C, & D would be sourced from the proxy,
> > which would be the last stop on the Via list of each forked INVITE.  A
> > would never see any responses to the proxy's forked INVITEs.
>
>This is not correct. The INVITE is originated at A. When the proxy
>forks, it does not re-originate the request. It will add a Via header,
>different for each forked request in the branch-id parameter. Thus, the
>three provisional responses can all be distinguished at the proxy. The
>proxy should forward all three upstream, even if its stateful. In fact,
>since the proxy forked, its not allowed to be stateless. The UAC will be
>able to distinguish the provisional responses by tag in the To field.

OK, I was confused here.  To do this right, the UAC should be able to setup 
QoS with all the potential target UASs, and then release the unused 
reservations when a 200 OK arrives.

>You also wrote:
> > > If peers include a key (and crypto algorithm, key length, etc.) in the
> > > session description (for example, using a k= tag in SDP), instead of 
> later
> > > using IKE to establish an SA, do they include "Session: Security"?
> >
>
>Including a k= tag in SDP is probably not the best way to establish a SA
>for the media session. It is completely insecure unless the SIP message
>is encrypted, and there are some issues with blind encryption of SIP
>messages before the called parties identity is known. The security task
>force is considering the right approach for this.

Some of Cisco's customers were interested in a combination of hop-by-hop 
signaling encryption with RTP payload encryption, since this method works 
with SIP, MGCP, or MEGACO.  I don't think there is a one-size fits all 
approach, so Cisco will probably support this model as well as the 
Digest/PGP model (and perhaps others as well).

I'd be happy to provide you with more detail if you are interested.

thanks,
-rohan




From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 23:04:07 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05835
	for ; Wed, 22 Mar 2000 23:04:07 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id CB44F52D5; Wed, 22 Mar 2000 23:01:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 46CD252DB; Wed, 22 Mar 2000 23:01:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 6ABD652D5
	for ; Wed, 22 Mar 2000 23:01:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 23:00:55 EST 2000
Received: from tonnant.cnchost.com ([207.155.248.72]) by dusty; Wed Mar 22 23:00:55 EST 2000
Received: from pc1 (gw-ss8networks.storm.ca [209.87.234.122])
	by tonnant.cnchost.com
	id XAA22751; Wed, 22 Mar 2000 23:00:48 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
From: "Li Li" 
To: "Jonathan Rosenberg" 
Cc: , 
Subject: RE: comments on draft-rosenberg-sip-3pcc-00.txt
Date: Wed, 22 Mar 2000 23:02:12 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <38D865FE.682E4796@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Jonathan wrote:
> 
>> Indeed a very good and very useful feature.
> >One question just for clarification.
> 
>> When the controller sends the separate INVITE's
>> to the parties to be involved in the call, what
>> should be used in the from, to and call-id headers
>> to form the call leg? The two INVITE's may have
>> the same call leg, which means the caler and callee
>> may not know there's a controller involved.

>Whilst this would be nice, I have concerns that this will break every
>security capability. Basically, the controller would be lying about its
>identity.

Or the controller doesn't have to lie. It can indicate to both 
parties that it's the controller who starts this call (in a new header?). 
Then the controller can leave as it doesn't want to stay in the call. 
If the controller wants to stay, it'd then use different call legs to 
link the involved parties as described in the 3pcc model. To get 
other parties connected without itself staying in the call can be
useful in some cases. Would this work?

We can argue that if the controller wants to connect A and B but doesn't 
want to stay in their call could use call transfer to achieve this, though 
that'd require a few more steps.   

> The Call-ID for each of the two INVITEs can be different. The To fields
> will also be different, reflecting the two addresses being contacted.
> The From field will probably need to contain an identifier for the
> controller.

Thanks for the clarifications.

li li

Li Li
SS8 Networks Ltd. 
135 Michael Cowpland Drive, Suite 200, 
Kanata, Ontario, K2M 2E9, Canada
tel: 613 592 4686
email: lili@ss8networks.com 




From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 23:21:58 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11306
	for ; Wed, 22 Mar 2000 23:21:58 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 1548852DB; Wed, 22 Mar 2000 23:19:25 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 82D8E52DD; Wed, 22 Mar 2000 23:19:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 1363052DB
	for ; Wed, 22 Mar 2000 23:19:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Mar 22 23:18:18 EST 2000
Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 22 23:17:49 EST 2000
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA01246;
	Thu, 23 Mar 2000 10:15:16 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652568AB.0017A66C ; Thu, 23 Mar 2000 09:48:19 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: "Li Li" 
Cc: "Jonathan Rosenberg" ,
        sip@lists.research.bell-labs.com, schulzrinne@cs.columbia.edu
Message-ID: <652568AB.0017A582.00@sampark.hss.hns.com>
Date: Thu, 23 Mar 2000 09:48:16 +0530
Subject: RE: comments on draft-rosenberg-sip-3pcc-00.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk



Hi,
actually initially I too was thinking of methods which would allow a
controller to step out just after indicating to n parties that they
need to contact each other - that way its a clear two-way usual call
without signals going one way and media another.

Infact, if you really want to do it that way, why couldnt a controller
simply send an INFO to A - telling it that it needs to contct B ?
You dont need any call transfer or whatever.
(of course, this INFO has to be understood by both parties - not a problem
if this issue is important enought to standardize the INFO format a little
more)

Anyway, I do agree with Jonathan that this draft specifies a
controller-is-present model and that there are other ways as he said like
pint, and maybe INFO  too - depends on what approach is taken.


Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems



> Or the controller doesn't have to lie. It can indicate to both
>  parties that it's the controller who starts this call (in a new
header?).
>  Then the controller can leave as it doesn't want to stay in the call.
>  If the controller wants to stay, it'd then use different call legs to
>  link the involved parties as described in the 3pcc model. To get
>  other parties connected without itself staying in the call can be
>  useful in some cases. Would this work?

> We can argue that if the controller wants to connect A and B but doesn't
>  want to stay in their call could use call transfer to achieve this,
though
>  that'd require a few more steps.

>> The Call-ID for each of the two INVITEs can be different. The To fields
>> will also be different, reflecting the two addresses being contacted.
>> The From field will probably need to contain an identifier for the
>> controller.





From owner-sip-outgoing@lists.research.bell-labs.com  Wed Mar 22 23:39:58 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17387
	for ; Wed, 22 Mar 2000 23:39:57 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 348A652DA; Wed, 22 Mar 2000 23:37:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A86EE52DE; Wed, 22 Mar 2000 23:37:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 2D5E052DA
	for ; Wed, 22 Mar 2000 23:37:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 22 23:36:38 EST 2000
Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Mar 22 23:36:35 EST 2000
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA06860;
	Thu, 23 Mar 2000 10:34:07 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652568AB.00195DAB ; Thu, 23 Mar 2000 10:07:03 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: Krishan Veer 
Cc: sip@lists.research.bell-labs.com
Message-ID: <652568AB.00195D71.00@sampark.hss.hns.com>
Date: Thu, 23 Mar 2000 10:06:58 +0530
Subject: Re: Reg SIPURL:
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=o240b88Y6Gr9uee1JejPiN1i5dXUdRiiCo3GTvcCjSLc1NdjeiclrBdW"
Content-Disposition: inline
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

--0__=o240b88Y6Gr9uee1JejPiN1i5dXUdRiiCo3GTvcCjSLc1NdjeiclrBdW
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hi,
Tag is defined in From and To headers.
Its not a part of a sip-url


From 6.22 and 6.41 of 2543bis

From = ( "From" | "f" ) ":" ( name-addr j addr-spec ) *( ";" addr-params )
To = ( " To" | "t" ) ":" ( name-addr j addr-spec )*( ";" addr-params )


addr-params = tag-param| addr-extension
tag-param = "tag=" UUID
UUID = 1*( hex j "-" )
addr-extension = token [ "=" ( token j quoted-string ) ]


Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems






Krishan Veer  on 03/23/2000 09:35:34 AM

To:   sip@lists.research.bell-labs.com
cc:

Subject:  Reg SIPURL:




Hi !

My query  is in context of  : is "tag" part of URL -parameters ? , if we
look at the specs in rfc2543 on SIP-URL Syntax (figure 3),
"url-parameter = transport-parm | user-parm | method-param | ttl-param|
maddr-param | other-param "
it says nothing about "tag" though "tag" is field there !!!. Should we
include tag in URLparameter or other-param.?.

thanks  ; )

--
Krishan veer
Software Engineer
http://www.vovida.com
"Fueling the Communications Revolution"




--0__=o240b88Y6Gr9uee1JejPiN1i5dXUdRiiCo3GTvcCjSLc1NdjeiclrBdW
Content-type: text/html; 
	name="att-1.htm"
Content-Disposition: attachment; filename="att-1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv
L2VuIj4NCjxodG1sPg0KSGkgIQ0KPHA+TXkgcXVlcnkmbmJzcDsgaXMgaW4gY29udGV4dCBvZiZu
YnNwOyA6IGlzICJ0YWciIHBhcnQgb2YgVVJMIC1wYXJhbWV0ZXJzDQo/ICwgaWYgd2UgbG9vayBh
dCB0aGUgc3BlY3MgaW4gcmZjMjU0MyBvbiBTSVAtVVJMIFN5bnRheCAoZmlndXJlIDMpLA0KPGJy
PiJ1cmwtcGFyYW1ldGVyID0gdHJhbnNwb3J0LXBhcm0gfCB1c2VyLXBhcm0gfCBtZXRob2QtcGFy
YW0gfCB0dGwtcGFyYW18DQptYWRkci1wYXJhbSB8IG90aGVyLXBhcmFtICINCjxicj5pdCBzYXlz
IG5vdGhpbmcgYWJvdXQgInRhZyIgdGhvdWdoICJ0YWciIGlzIGZpZWxkIHRoZXJlICEhIS4gU2hv
dWxkDQp3ZSBpbmNsdWRlIHRhZyBpbiBVUkxwYXJhbWV0ZXIgb3Igb3RoZXItcGFyYW0uPy4NCjxw
PnRoYW5rcyZuYnNwOyA7ICkNCjxwcmU+LS0mbmJzcDsNCktyaXNoYW4gdmVlcg0KU29mdHdhcmUg
RW5naW5lZXINCjxBIEhSRUY9Imh0dHA6Ly93d3cudm92aWRhLmNvbSI+aHR0cDovL3d3dy52b3Zp
ZGEuY29tPC9BPg0KIkZ1ZWxpbmcgdGhlIENvbW11bmljYXRpb25zIFJldm9sdXRpb24iPC9wcmU+
DQombmJzcDs8L2h0bWw+DQoNCg==

--0__=o240b88Y6Gr9uee1JejPiN1i5dXUdRiiCo3GTvcCjSLc1NdjeiclrBdW--




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 23 00:13:23 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29466
	for ; Thu, 23 Mar 2000 00:13:23 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id CE8A552DF; Thu, 23 Mar 2000 00:09:47 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 3C67152DE; Thu, 23 Mar 2000 00:09:47 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id C74BC52DF
	for ; Thu, 23 Mar 2000 00:09:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 23 00:08:55 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu Mar 23 00:08:54 EST 2000
Received: from dynamicsoft.com (1Cust50.tnt1.freehold.nj.da.uu.net [63.17.113.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA09926;
	Thu, 23 Mar 2000 00:10:02 -0500 (EST)
Message-ID: <38D9A88B.12835052@dynamicsoft.com>
Date: Thu, 23 Mar 2000 00:15:55 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: archow@hss.hns.com
Cc: Li Li , sip@lists.research.bell-labs.com,
        schulzrinne@cs.columbia.edu
Subject: Re: comments on draft-rosenberg-sip-3pcc-00.txt
References: <652568AB.0017A582.00@sampark.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



archow@hss.hns.com wrote:
> 
> Hi,
> actually initially I too was thinking of methods which would allow a
> controller to step out just after indicating to n parties that they
> need to contact each other - that way its a clear two-way usual call
> without signals going one way and media another.
> 
> Infact, if you really want to do it that way, why couldnt a controller
> simply send an INFO to A - telling it that it needs to contct B ?

We have discussed that as well (OPTIONS with Also was the initial
proposal). It suffers from the problem that there isn't much feedback on
call state to the controller, and no subsequent control is possible.
Thus, it doesn't solve much.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 23 00:39:00 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09674
	for ; Thu, 23 Mar 2000 00:38:59 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 6030F52DE; Thu, 23 Mar 2000 00:34:12 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8326452E0; Thu, 23 Mar 2000 00:34:11 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 4208052DE
	for ; Thu, 23 Mar 2000 00:33:09 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 23 00:32:43 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu Mar 23 00:32:43 EST 2000
Received: from dynamicsoft.com (1Cust50.tnt1.freehold.nj.da.uu.net [63.17.113.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA09992;
	Thu, 23 Mar 2000 00:33:52 -0500 (EST)
Message-ID: <38D9AE21.4EB27B1A@dynamicsoft.com>
Date: Thu, 23 Mar 2000 00:39:45 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sunitha Kumar 
Cc: SIPbell-labs 
Subject: Re: question on sip url grammar.
References: <38CFE25B.54D62B30@vovida.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Sunitha Kumar wrote:
> 
> A question on BNF grammar in SIP url.
> In BNF RFC, it is given that [       stands for 0 or 1 times the
> value.
> It is given
> 
> SIP-URL = "sip:"  [userinfo '@'] hostport url-parameters....
> user-info = user [":"password]
> user = *(unreserved... )                          //optional
> 
> password = *(unreserved ...)                 //optional.
> 
> so, this leads to a url as:
> 
> sip::@hostport.                  So, with the above grammar, this is
> valid.
> is my understanding right?

Yes.

> 
> Also, for hostport;
> 
> sip:userinfo@host:urlparms            //since port is optional.

There will always be a semicolon before the urlparams, so:

sip:userinfo@host:;urlparams

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 23 00:45:12 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12118
	for ; Thu, 23 Mar 2000 00:45:11 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id AA4C752E1; Thu, 23 Mar 2000 00:40:36 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A52F552DD; Thu, 23 Mar 2000 00:40:35 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 0C46C52E1
	for ; Thu, 23 Mar 2000 00:39:18 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 23 00:37:41 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu Mar 23 00:37:40 EST 2000
Received: from dynamicsoft.com (1Cust50.tnt1.freehold.nj.da.uu.net [63.17.113.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA10012;
	Thu, 23 Mar 2000 00:38:49 -0500 (EST)
Message-ID: <38D9AF49.1815B39F@dynamicsoft.com>
Date: Thu, 23 Mar 2000 00:44:41 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert.Sparks@wcom.com
Cc: "'Henning Schulzrinne'" ,
        sip@lists.research.bell-labs.com
Subject: Re: Comments on transfer draft (sparks-sip-cc-transfer-00)
References: <002c01bf9413$955490e0$999923a6@mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

I think we are now arguing about what consists of SIP engine, and what
doesn't. For the purposes of this draft, I think its OK to say the
request MAY contain a body, and that the UAS SHOULD reject the request
if it doesn't know how to handle that body (same as always) in a
TRANFER.

-Jonathan R.

Robert Sparks wrote:
> 
> Jonathan Rosenberg wrote:
> > SDP doesn't affect the processing of the SIP engine, only the
> > component
> > thats handling the media session. In general, a body should not change
> > the basic semantic of the request. If a UAS doesn't know what
> > to do with
> > a body in a particular request, it should reject it.
> 
> The contents of the SDP body may not affect the processing
> in the SIP engine (past the inclusion of warning headers and
> maybe choosing a different response code if it fails to parse),
> but the presence/absence of the body in the INVITE request does.
> 
>                             |
> INVITE   200 OK     ACK     vs   INVITE    200 OK   ACK
> SDP      SDP        noSDP   |    noSDP     SDP      SDP
> 
> RjS

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 23 01:11:58 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22763
	for ; Thu, 23 Mar 2000 01:11:57 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 2E8C452DD; Thu, 23 Mar 2000 01:09:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6DCB152E2; Thu, 23 Mar 2000 01:09:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id DC1FB52DD
	for ; Thu, 23 Mar 2000 01:09:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 23 01:08:15 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu Mar 23 01:08:14 EST 2000
Received: from dynamicsoft.com (1Cust50.tnt1.freehold.nj.da.uu.net [63.17.113.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA10066;
	Thu, 23 Mar 2000 01:09:23 -0500 (EST)
Message-ID: <38D9B674.11BCC928@dynamicsoft.com>
Date: Thu, 23 Mar 2000 01:15:16 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Li Li 
Cc: sip@lists.research.bell-labs.com, schulzrinne@cs.columbia.edu
Subject: Re: comments on draft-rosenberg-sip-3pcc-00.txt
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Li Li wrote:
> 
> Jonathan wrote:
> >
> >> Indeed a very good and very useful feature.
> > >One question just for clarification.
> >
> >> When the controller sends the separate INVITE's
> >> to the parties to be involved in the call, what
> >> should be used in the from, to and call-id headers
> >> to form the call leg? The two INVITE's may have
> >> the same call leg, which means the caler and callee
> >> may not know there's a controller involved.
> 
> >Whilst this would be nice, I have concerns that this will break every
> >security capability. Basically, the controller would be lying about its
> >identity.
> 
> Or the controller doesn't have to lie. It can indicate to both
> parties that it's the controller who starts this call (in a new header?).

Authentication is done based on the From field, so adding a new header
doesn't help.

> Then the controller can leave as it doesn't want to stay in the call.
> If the controller wants to stay, it'd then use different call legs to
> link the involved parties as described in the 3pcc model. To get
> other parties connected without itself staying in the call can be
> useful in some cases. Would this work?

No. As I said, these call legs are different.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 23 04:10:05 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01971
	for ; Thu, 23 Mar 2000 04:10:05 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 6AEE652E0; Thu, 23 Mar 2000 04:07:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D933652E3; Thu, 23 Mar 2000 04:07:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 4B5AB52E0
	for ; Thu, 23 Mar 2000 04:07:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 23 04:06:44 EST 2000
Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Thu Mar 23 04:06:40 EST 2000
Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22])
	by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id PAA14714;
	Thu, 23 Mar 2000 15:04:12 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652568AB.00321A7D ; Thu, 23 Mar 2000 14:37:15 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: Jonathan Rosenberg 
Cc: archow@hns.com, Li Li ,
        sip@lists.research.bell-labs.com
Message-ID: <652568AB.003219A2.00@sampark.hss.hns.com>
Date: Thu, 23 Mar 2000 14:37:12 +0530
Subject: Re: comments on draft-rosenberg-sip-3pcc-00.txt
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk



Yes you are right. If someone chooses the INFO (or whatever method), he
does not want the controller to intervene
anyway, so its not a handicap - so if the controller does not get any
feedback - well thats how he wanted it.

Anyway, its not entirely true that if the controller is not *directly* in
the control path, that it will get no feed back

One set on people I once interacted with wanted the following setup:

They already had a little SIP server (kindof) and they wanted to regulate
some prototype clients we wrote just so that when
a client established a call, a notice would go to the server, and when the
client terminated, a notice would go to the server - they
wanted to show it in their logs. They did *not* want to route all signals
through their server.

so we decided to do something like a willSupplyUUIE in H,323.

When the clients registered with the server, the Sever would send them an
INFO message with a header we defined on our own
which would ask the client to send an INFO back to the server whenever it
either connected or disconnected (the header was proprietary of course).
The client would either OK it or send a Bad Response - in which case the
server would kick out his registration.

So client would talk directly to each other, and whenever it either set up
or broke up, it would send an INFO to the server.

So the server got feedback from the clients without having to route all
message, including retransmissions to and fro.

Anyway, I guess there are always ways to do it. We just happened to do it
in the above way.

(Of course, there are issues like trust - what happens if the clients dont
send ? or will a client accept a commandfrom the controller
  incase all of a sudden it decides to step in actively etc -pbly with some
thought they could be resolved - if it is needed ?)

Just thought Id menton this, incase someone thought willSupplyUUIE was a
nice thing to do without the 'controller' sitting in-between always

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems



jr> We have discussed that as well (OPTIONS with Also was the initial
jr>  proposal). It suffers from the problem that there isn't much feedback
on
jr>  call state to the controller, and no subsequent control is possible.
jr>  Thus, it doesn't solve much.

jr>  -Jonathan R.


> without signals going one way and media another.
>
> Infact, if you really want to do it that way, why couldnt a controller
> simply send an INFO to A - telling it that it needs to contct B ?






From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 23 10:54:19 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26115
	for ; Thu, 23 Mar 2000 10:54:19 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3DE1352E2; Thu, 23 Mar 2000 10:51:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B035652E4; Thu, 23 Mar 2000 10:51:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 08A3852E2
	for ; Thu, 23 Mar 2000 10:51:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 23 10:50:30 EST 2000
Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Mar 23 10:50:29 EST 2000
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA03797
	for ; Thu, 23 Mar 2000 10:50:28 -0500 (EST)
Message-ID: <38DA3D44.4B4705C3@cs.columbia.edu>
Date: Thu, 23 Mar 2000 10:50:28 -0500
From: Henning Schulzrinne 
Organization: Columbia University, Dept. of Computer Science
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: RFC2543bis draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

It's a long flight to Adelaide, so here's your free reading material if
you didn't get to the Steven King novella: I've created a snapshot of
the RFC 2543bis draft, available at http://www.cs.columbia.edu/sip.
After Adelaide, I'd like to make this a 'real' Internet draft, but it
would be nice to fix as many things as possible early on.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 24 01:27:06 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06504
	for ; Fri, 24 Mar 2000 01:27:06 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 5C02E52C4; Fri, 24 Mar 2000 01:23:35 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B657F52E6; Fri, 24 Mar 2000 01:23:34 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id DE99E52C4
	for ; Fri, 24 Mar 2000 01:23:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 24 01:21:42 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Fri Mar 24 01:21:41 EST 2000
Received: from dynamicsoft.com ([63.25.143.183])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA12735;
	Fri, 24 Mar 2000 01:22:51 -0500 (EST)
Message-ID: <38DB08BC.1712F66F@dynamicsoft.com>
Date: Fri, 24 Mar 2000 01:18:36 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sunitha Kumar ,
        SIPbell-labs 
Subject: Re: question on sip url grammar.
References: <38CFE25B.54D62B30@vovida.com> <38D9AE21.4EB27B1A@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Henning pointed out to me that the BNF for host is not right. RFC1630
defines port as

port = digits
digits = digit [digits]

and RFC 1738 as

digits = 1*digit

which is what we should use (instead of the current *digit). This will
be fixed.

In this case, you could not have:

sip:user@host:;url-params

-Jonathan R.

Jonathan Rosenberg wrote:
> 
> Sunitha Kumar wrote:
> >
> > A question on BNF grammar in SIP url.
> > In BNF RFC, it is given that [       stands for 0 or 1 times the
> > value.
> > It is given
> >
> > SIP-URL = "sip:"  [userinfo '@'] hostport url-parameters....
> > user-info = user [":"password]
> > user = *(unreserved... )                          //optional
> >
> > password = *(unreserved ...)                 //optional.
> >
> > so, this leads to a url as:
> >
> > sip::@hostport.                  So, with the above grammar, this is
> > valid.
> > is my understanding right?
> 
> Yes.
> 
> >
> > Also, for hostport;
> >
> > sip:userinfo@host:urlparms            //since port is optional.
> 
> There will always be a semicolon before the urlparams, so:
> 
> sip:userinfo@host:;urlparams
> 
> -Jonathan R.
> --
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com





From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 24 01:30:16 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08179
	for ; Fri, 24 Mar 2000 01:30:15 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 1C91152E7; Fri, 24 Mar 2000 01:23:42 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 411F452E5; Fri, 24 Mar 2000 01:23:36 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 6C3F152E5
	for ; Fri, 24 Mar 2000 01:23:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 24 01:21:36 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Fri Mar 24 01:21:35 EST 2000
Received: from dynamicsoft.com ([63.25.143.183])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA12727;
	Fri, 24 Mar 2000 01:22:44 -0500 (EST)
Message-ID: <38DB0645.1D2C6FA7@dynamicsoft.com>
Date: Fri, 24 Mar 2000 01:08:05 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Donovan, Steven R." 
Cc: sip@lists.research.bell-labs.com
Subject: Re: Comment on draft-ietf-sip-isup-mime-00.txt
References: <75C79E507864D3118AFC00805FEAB7D8349381@ripexch001.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Donovan, Steven R." wrote:
> 
> One quick comment on the security section of this draft.  I agree that it is
> true that the security section in SIP that discusses end-to-end encryption
> of the SIP message body should be sufficient to meet the security concerns
> associated with carrying ISUP and QSIG message bodies.
> 
> I would, however, suggest that the following be added to the spec:
> 
> "Due to the potentially sensitive nature of the information contained in
> ISUP and QSIG message bodies, the UAC SHOULD perform end-to-end encryption
> on ISUP and QSIG message bodies."

Lets be careful here. It depends on the application of SIP-T. For single
provider networks among a set of  softswitches, its easy to manage keys
in such a way that e2e encryption is possible. For multi-provider, wide
area operation, e2e encryption is harder, and I'm reluctant to make it
SHOULD. It requires the originator to know the key of the ultimate
recipient before sending the request. Since the entity the request will
terminate on can't always be known ahead of time (due to forwarding or
routing to a remote gateway), this requirement is overly strong.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com





From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 24 01:32:15 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09306
	for ; Fri, 24 Mar 2000 01:32:15 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 4481952E5; Fri, 24 Mar 2000 01:27:52 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id DDD1D52E8; Fri, 24 Mar 2000 01:27:50 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id BBA9E52E5
	for ; Fri, 24 Mar 2000 01:27:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 24 01:25:19 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Fri Mar 24 01:25:18 EST 2000
Received: from dynamicsoft.com ([63.25.143.183])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA12723;
	Fri, 24 Mar 2000 01:22:41 -0500 (EST)
Message-ID: <38DB0555.1EEEDF10@dynamicsoft.com>
Date: Fri, 24 Mar 2000 01:04:05 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen 
Cc: Henning Schulzrinne ,
        SIP 
Subject: Re: Session timer comments
References: <38CCEB34.E5CE4B41@hplb.hpl.hp.com> <38D873C1.D2797AA7@dynamicsoft.com> <38D8B67C.E4A14A16@hplb.hpl.hp.com> <38D8DD11.1809CF54@cs.columbia.edu> <38D8E2A4.FD004D4C@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Anders Kristensen wrote:
> 
> Henning Schulzrinne wrote:
> >
> > Anders Kristensen wrote:
> > >
> > > A non-200 status makes sense in responses to "traditional" re-INVITEs
> > > whose purpose it is to modify the media streams, but I don't see what
> > > purpose a non-200 response could possibly have for re-INVITEs whose sole
> > > purpose it is to refresh the session timer. Are you saying refreshing
> > > the session timer can fail?
> >
> > While not likely, this is possible. Imagine that the UAS crashes and
> > then comes back to life, minus recollection of call-id in the timer
> > refresh. In that case, a failure is quite likely. (The resurrected UAS
> > would treat it as a new call, which would be appropriate, but the user
> > might refuse the new call or something else might go wrong.)
> 
> Excellent point, but isn't this just another argument for using a
> non-INVITE method? In this case, by using INVITE the timer refresh
> operation might be interpreted as a regular, brand new INVITE, whereas
> with a non-INVITE method the refresh would correctly be recognized as
> belonging to an "old" call and would be rejected with a 481 just like,
> say, a BYE received for an old call after a UAS comes back up after a
> crash.

The argument is that you WANT it to look like a regular, new invite.
This means, for example, the UAC can crash, and when it comes back up,
the call in progress can be re-established afresh.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com





From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 24 01:35:34 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10977
	for ; Fri, 24 Mar 2000 01:35:33 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id A7FF152EA; Fri, 24 Mar 2000 01:28:34 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 889D352E6; Fri, 24 Mar 2000 01:28:25 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id EBC0F52E6
	for ; Fri, 24 Mar 2000 01:27:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 24 01:25:24 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Fri Mar 24 01:25:24 EST 2000
Received: from dynamicsoft.com ([63.25.143.183])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA12731;
	Fri, 24 Mar 2000 01:22:48 -0500 (EST)
Message-ID: <38DB0749.79CCE135@dynamicsoft.com>
Date: Fri, 24 Mar 2000 01:12:25 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen 
Cc: SIP 
Subject: Re: Session timer comments
References: <38CCEB34.E5CE4B41@hplb.hpl.hp.com> <38D873C1.D2797AA7@dynamicsoft.com> <38D8B67C.E4A14A16@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Anders Kristensen wrote:
> 
> > > This seems to me to be a big problem. It means there are circumstances
> > > under which a call-statefull proxy *cannot* protect itself against DoS
> > > attacks. It *must* allow the session to proceed without timers.
> > >
> > > Fortunately there may be a simple solution: when a UAC sends an INVITE
> > > through a proxy indicating that it supports the 'timer' extension but
> > > without either "Require: timer" and "Session-Expires:" headers the proxy
> > > inserts a "Require: timer" before forwarding the INVITE:
> >
> > Interesting idea. It might work. A few issues:
> >
> > 1. If the request is signed, and the Require header is below the
> > Authorization header, the proxy can't muck with it.
> 
> Right, but in this case I suppose adding another Require header above
> the Authorization header wont hurt.

Hmm, I think this is OK.

> 
> > 2. The UAC is going to be confused. It sent a request without a Require
> > header, and gets a 420 listing some random extension as being
> > Unsupported. What does it do then?
> 
> The draft would mandate that the UAC treat this case as if it had itself
> required the 'timer' extension in the first case, i.e. the INVITE fails
> as it should do.  This is not to say that requests in general can fail
> with 420 for extensions they didn't Require. The draft would allow it
> specifically for the case where a UAC sends an INVITE indicating
> "Supported: timer" without "Require: timer". Like I said in the original
> posting I believe this is acceptable because its basically a matter of
> definition. If a UA supports the 'timer' extension it is required to
> understand this special case.

OK, sounds like this might work. Its a bit ugly, since it makes the
Require/420 mechanism different for this extension. I'll raise this
issue during the meeting and see if we can come up with any other
interactions this might introduce.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com





From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 24 02:56:27 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17263
	for ; Fri, 24 Mar 2000 02:56:26 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id A969C52AB; Fri, 24 Mar 2000 02:53:38 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 1F50052E8; Fri, 24 Mar 2000 02:53:37 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 8D04752AB
	for ; Fri, 24 Mar 2000 02:53:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 24 02:52:30 EST 2000
Received: from exchangesvr.nuera.com ([204.216.240.124]) by dusty; Fri Mar 24 02:52:30 EST 2000
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 23 Mar 2000 23:52:54 -0800
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'sip@lists.research.bell-labs.com'" 
Subject: SIP Request Glare.
Date: Thu, 23 Mar 2000 23:52:53 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


I refer to the clarification on "The SIP Page":

---
	CSeq
	The spec is not clear on whether both parties "share" the CSeq
space. In other words, if A sends an INVITE to B with CSeq: 0, and then B
sends a BYE to A, does B need use CSeq:1 in its BYE? Answer: no. The CSeq
space is maintained independently in both directions. This raises a state
inconsistency issue. Lets say A and B are in a call, and A sends a re-INVITE
to B at the same time B sends it to A. It is possible that the transactions
complete in different orders at A and B, yielding an inconsistent view of
the session state. This is similar to the "glare" problem in telephony. The
solution: if A has a transaction pending (pending = no final response
received), and a request from the remote side arrives, it should send a 500
response (possibly with a Retry-After randomly generated to enable back-
off). This should (??) guarantee ordered completion of transactions. 
---
Firstly concerning, request ordering and pending requests: Does order
consistency condition extend to other methods, such as glare between
METHOD-INFO & INFO-INFO request for example ? If not, then INFO and INVITE
methods must be able execute independently (that is, you could have multiple
active requests: an INVITE and an INFO, or two INFOs). What is the correct
handling of this situation ? 

Now regarding glare resolution: Is the proposed glare resolution solution
acceptable in a telephony environment? The granularity of Retry-After is in
seconds. So to have a reasonable chance of not colliding again you must make
the random range large; yet it is unacceptable to have a delay any more than
a second or two in most telephony applications. For instance if the random
range of Retry-After is up to three seconds, then this only allows three
random outcomes => leading to a roughly 33% chance of re-collision.
Additionally, even for this small value of Retry-After there is roughly only
a 66% chance that a request will commence within 2 seconds (which is still
unacceptable in many situations). Whether or not you have a small or large
random range for Retry-After doesn't help because of the lack of random
granularity.

We need a glare resolution that completes resolves quickly, does not starve
one side and has little chance of recollision. 

One possible solution might be to include a header field with a 32bit random
value ( eg Retry-Resolve?). Both sides can use this value to quickly resolve
the glare and the winner could instantly retransmit.

I am not sure if I have "gone off the rails" somewhere along the way but to
me it seems like this is a pretty big hole in the protocol. What are people
doing at the moment?

Cheers,

Robert.












From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 24 13:56:02 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08569
	for ; Fri, 24 Mar 2000 13:56:01 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 30D5252C4; Fri, 24 Mar 2000 13:53:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8B6AC52D4; Fri, 24 Mar 2000 13:53:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 0CF8752C4
	for ; Fri, 24 Mar 2000 13:53:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 24 13:53:00 EST 2000
Received: from atlrel2.hp.com ([156.153.255.202]) by dusty; Fri Mar 24 13:52:59 EST 2000
Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2])
	by atlrel2.hp.com (Postfix) with ESMTP
	id A8E69C4D; Fri, 24 Mar 2000 13:52:55 -0500 (EST)
Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238])
	by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA29661;
	Fri, 24 Mar 2000 18:52:51 GMT
Message-ID: <38DBB9A7.9B72DFD@hplb.hpl.hp.com>
Date: Fri, 24 Mar 2000 18:53:27 +0000
From: Anders Kristensen 
Organization: HP Labs
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: Henning Schulzrinne ,
        SIP 
Subject: Re: Session timer comments
References: <38CCEB34.E5CE4B41@hplb.hpl.hp.com> <38D873C1.D2797AA7@dynamicsoft.com> <38D8B67C.E4A14A16@hplb.hpl.hp.com> <38D8DD11.1809CF54@cs.columbia.edu> <38D8E2A4.FD004D4C@hplb.hpl.hp.com> <38DB0555.1EEEDF10@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Jonathan Rosenberg wrote:
> 
> Anders Kristensen wrote:
> >
> > Henning Schulzrinne wrote:
> > >
> > > Anders Kristensen wrote:
> > > >
> > > > A non-200 status makes sense in responses to "traditional" re-INVITEs
> > > > whose purpose it is to modify the media streams, but I don't see what
> > > > purpose a non-200 response could possibly have for re-INVITEs whose sole
> > > > purpose it is to refresh the session timer. Are you saying refreshing
> > > > the session timer can fail?
> > >
> > > While not likely, this is possible. Imagine that the UAS crashes and
> > > then comes back to life, minus recollection of call-id in the timer
> > > refresh. In that case, a failure is quite likely. (The resurrected UAS
> > > would treat it as a new call, which would be appropriate, but the user
> > > might refuse the new call or something else might go wrong.)
> >
> > Excellent point, but isn't this just another argument for using a
> > non-INVITE method? In this case, by using INVITE the timer refresh
> > operation might be interpreted as a regular, brand new INVITE, whereas
> > with a non-INVITE method the refresh would correctly be recognized as
> > belonging to an "old" call and would be rejected with a 481 just like,
> > say, a BYE received for an old call after a UAS comes back up after a
> > crash.
> 
> The argument is that you WANT it to look like a regular, new invite.
> This means, for example, the UAC can crash, and when it comes back up,
> the call in progress can be re-established afresh.

I would question the wisdom of attempting to do this, partly because I
don't think it can be made to work well, and partly because I'm not
convinced it's something we'd really want to do anyway.

There are several reasons I can think of why it won't work:

 o The To tag of re-INVITEs will (usually) be non-null. When a UAS
receives an INVITE with a non-null To tag and it has no knowledge of the
leg it is rejected. 

 o The crashed UA may have had a route associated with the leg. Allowing
a re-INVITE to set up a leg in the crashed UAS as if it was an original
INVITE ignores the fact that subsequent requests should follow a route
established prior to the crash.

 o Many types of media streams may not be tolerant towards this sort of
re-establishment long after the initial session initiation. Consider,
for example, a chat media stream using TCP. The caller might accept a
TCP connection in the time between having sent the initial INVITE and
receiving the 200. Such a media stream may not be capable of being
reestablished if a crashed UAS comes back up and attempts to patch up
the session, even if at the SIP level the session could be picked up
properly again.

For these reasons I think that after a crash it is necessary for user
agents to reject requests belonging to old calls. Of course this is only
possible if it can reliably recognize when the request is indeed for an
old call and not an INVITE for a new call.

Anders

-- 
Anders Kristensen ,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 24 14:04:04 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11755
	for ; Fri, 24 Mar 2000 14:04:03 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id D49DF52D5; Fri, 24 Mar 2000 14:01:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5568452D4; Fri, 24 Mar 2000 14:01:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 20C3752D4
	for ; Fri, 24 Mar 2000 14:01:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Mar 24 13:59:47 EST 2000
Received: from mail-dns1-nj.dialogic.com ([146.152.228.10]) by dusty; Fri Mar 24 13:59:46 EST 2000
Received: from mail4.dialogic.com ([146.152.6.40])
	by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id TAA16408;
	Fri, 24 Mar 2000 19:01:29 GMT
Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18])
 by mail4.dialogic.com (PMDF V5.2-31 #40816)
 with ESMTP id <0FRX00BJLWRFWE@mail4.dialogic.com>; Fri,
 24 Mar 2000 13:59:39 -0500 (EST)
Received: by mailnj.dialogic.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 24 Mar 2000 13:59:41 -0500
Content-return: allowed
Date: Fri, 24 Mar 2000 13:59:56 -0500
From: "Kelley, Kalon" 
Subject: RE: SIP Request Glare.
To: "'Fairlie-Cuninghame, Robert'" ,
        "'sip@lists.research.bell-labs.com'" 
Cc: "'Jeff.Mark@dialogic.com'" 
Message-id: <3E006CE92E9AD3119F4E00105A0C3807C5811F@exchange1nj.dialogic.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Robert:

I agree completely with your assertion that the current glare resolution
mechanism seems inadequate, for most of the reasons you cited.

I've got to admit that I didn't even notice that the specification states
that the specified Retry-After delay must be an integer number of seconds,
which, as you clearly demonstrate, requires the introduced delay to be
unacceptably large.  Even if this requirement were relaxed, however, the
introduced random back-off must still be large enough to ensure that the
difference between both sides' random delays will almost always exceed the
time it takes to transmit the message across the network (so that one side
will receive the other side's invitation before sending its own.)  I suspect
that this means that the introduced delay will often exceed the maximum
acceptable "second or two".

I don't know what most implementers are doing at present.  I suspect the
issue hasn't come up a lot because the rate of incidence of crossing INVITEs
in point-to-point communications is probably quite low.  I believe, however,
that the problem is more common in multipoint conferences with decentralized
control, which is what brought the problem to my attention.

We've introduced an alternate proposal in a recent I-D (see, in particular,
section 7 of http://www.ietf.org/internet-drafts/draft-mark-sip-dmcs-00.txt)
that attempts to address the problem.  Loosely, our proposal entails
comparing the URIs used in the To and From fields of the INVITEs as the
basis for comparison.  The party whose URI is lesser is designated the
victor when crossing INVITEs arise.

This solution DOES starve one of the parties in this situation, contrary to
your stated requirements (in our draft, we consequently describe it as a
non-egalitarian approach.)  Although I'm not sure that a more egalitarian
approach is really required, we describe other approaches in section 7.5 of
the draft that respect this additional requirement.  Your Retry-Resolve
proposal is a specific implementation of one of the options we enumerate
there.

Is there a compelling reason why you believe that neither party should be
consistently favored?  If so, I'd readily embrace something akin to the
Retry-Resolve approach.  (It may be possible to do this without introducing
a new header; our draft describes an extension to our URI-comparison
proposal that uses CSeq values to eliminate concerns about starvation.)


Regards,

Kalon Kelley
Intel Dialogic Division
mailto:Kalon.Kelley@dialogic.com
http://www.dialogic.com/


> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
> Sent: Thursday, March 23, 2000 11:53 PM
> To: 'sip@lists.research.bell-labs.com'
> Subject: SIP Request Glare.
> 
> 
> 
> I refer to the clarification on "The SIP Page":
> 
> ---
> 	CSeq
> 	The spec is not clear on whether both parties "share" the CSeq
> space. In other words, if A sends an INVITE to B with CSeq: 
> 0, and then B
> sends a BYE to A, does B need use CSeq:1 in its BYE? Answer: 
> no. The CSeq
> space is maintained independently in both directions. This 
> raises a state
> inconsistency issue. Lets say A and B are in a call, and A 
> sends a re-INVITE
> to B at the same time B sends it to A. It is possible that 
> the transactions
> complete in different orders at A and B, yielding an 
> inconsistent view of
> the session state. This is similar to the "glare" problem in 
> telephony. The
> solution: if A has a transaction pending (pending = no final response
> received), and a request from the remote side arrives, it 
> should send a 500
> response (possibly with a Retry-After randomly generated to 
> enable back-
> off). This should (??) guarantee ordered completion of transactions. 
> ---
> Firstly concerning, request ordering and pending requests: Does order
> consistency condition extend to other methods, such as glare between
> METHOD-INFO & INFO-INFO request for example ? If not, then 
> INFO and INVITE
> methods must be able execute independently (that is, you 
> could have multiple
> active requests: an INVITE and an INFO, or two INFOs). What 
> is the correct
> handling of this situation ? 
> 
> Now regarding glare resolution: Is the proposed glare 
> resolution solution
> acceptable in a telephony environment? The granularity of 
> Retry-After is in
> seconds. So to have a reasonable chance of not colliding 
> again you must make
> the random range large; yet it is unacceptable to have a 
> delay any more than
> a second or two in most telephony applications. For instance 
> if the random
> range of Retry-After is up to three seconds, then this only 
> allows three
> random outcomes => leading to a roughly 33% chance of re-collision.
> Additionally, even for this small value of Retry-After there 
> is roughly only
> a 66% chance that a request will commence within 2 seconds 
> (which is still
> unacceptable in many situations). Whether or not you have a 
> small or large
> random range for Retry-After doesn't help because of the lack 
> of random
> granularity.
> 
> We need a glare resolution that completes resolves quickly, 
> does not starve
> one side and has little chance of recollision. 
> 
> One possible solution might be to include a header field with 
> a 32bit random
> value ( eg Retry-Resolve?). Both sides can use this value to 
> quickly resolve
> the glare and the winner could instantly retransmit.
> 
> I am not sure if I have "gone off the rails" somewhere along 
> the way but to
> me it seems like this is a pretty big hole in the protocol. 
> What are people
> doing at the moment?
> 
> Cheers,
> 
> Robert.



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 24 14:07:41 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12868
	for ; Fri, 24 Mar 2000 14:07:40 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 4716E52DA; Fri, 24 Mar 2000 14:03:54 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 34DB952DD; Fri, 24 Mar 2000 14:03:53 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id A762952DA
	for ; Fri, 24 Mar 2000 14:03:08 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 24 14:01:45 EST 2000
Received: from thumper.research.telcordia.com ([128.96.41.1]) by dusty; Fri Mar 24 14:01:44 EST 2000
Received: from mailee.research.telcordia.com (mailee [192.4.7.23])
	by thumper.research.telcordia.com (8.9.3/8.9.3) with ESMTP id OAA09484;
	Fri, 24 Mar 2000 14:01:42 -0500 (EST)
Received: from research.telcordia.com (VFaramak.cc.telcordia.com [128.96.54.222])
	by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id OAA02853;
	Fri, 24 Mar 2000 14:01:41 -0500 (EST)
Message-ID: <38DBBB93.11465731@research.telcordia.com>
Date: Fri, 24 Mar 2000 14:01:39 -0500
From: Faramak Vakil 
Organization: Telcordia Technologies
X-Mailer: Mozilla 4.06 [en] (WinNT; U)
MIME-Version: 1.0
To: SIP 
Subject: I-D draft-itsumo-sip-mobility-req-01.txt
Content-Type: multipart/mixed; boundary="------------46A0FC4882A58ED2814B335F"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------46A0FC4882A58ED2814B335F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

After posting version 00 of the above, we
received several comments. We have updated
the draft accordingly and will post it on the
IETF site after the Adelaide meeting. In the mean-time
attached is a copy for those who are interested.

Regards, Faramak

--------------46A0FC4882A58ED2814B335F
Content-Type: text/plain; charset=us-ascii; name="draft-itsumo-sip-mobility-req-01.txt"
Content-Disposition: inline; filename="draft-itsumo-sip-mobility-req-01.txt"
Content-Transfer-Encoding: 7bit







Internet Engineering Task Force                                  F.Vakil
INTERNET DRAFT                                                  A. Dutta
draft-itsumo-sip-mobility-req-01.txt                      Jyh-Cheng Chen
Date: March 2000                                  Telcordia Technologies
Expires: August 2000
                                                           Shinichi Baba
                                                        Yasuro Shobatake
                                           Toshiba America Research,Inc.

                                                     Henning Schulzrinne
                                                     Columbia University

               Mobility Management in a SIP Environment
                   Requirements, Functions and Issues
                 

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.  Internet- Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   The distribution of this memo is unlimited.  It is filed as , and expires August, 2000. Please send
   comments to farm@research.telcordia.com or sbaba@tari.toshiba.com, or
   Schulzrinne@cs.columbia.edu.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

ABSTRACT

   Mobility is rapidly becoming a rule rather than an exception in



ITSUMO Group                                                    [Page 1]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


   communication services and SIP is gaining widespread acceptance as
   the signaling protocol for multimedia applications on the Internet.
   Thus, it is essential to develop a mobility management scheme that
   utilizes salient features and capabilities of SIP as well as other
   protocols (e.g., mobile IP) to support mobile services efficiently.
   Without providing any specific solution, this document presents
   preliminary requirements and identifies the issues that need to be
   resolved in order to develop a mobility management scheme for
   supporting multimedia applications in a SIP signaling and control
   environment.

1. Purpose and Scope

   The increasing demand for mobile telephony, and the explosive growth
   of the Internet are driving forces behind the current boom in the
   communication industry. On the one hand, mobile wireless telephony is
   rapidly becoming ubiquitous. The difference between the prices of
   mobile and fixed telephone services is diminishing and users demand
   for continuous connectivity is on the rise. Thus, mobility is rapidly
   becoming a rule/norm rather than an exception, and mobile wireless
   applications and appliances are becoming predominant.  On the other
   hand, service/network providers/operators are rapidly expanding their
   IP infrastructure to support the explosive growth of the data traffic
   of the Internet users. The growth of data service market is much
   faster than that of telephony, and providers will invest much more in
   expanding the IP infrastructure than in expanding PSTN. Due to this
   lop-sided growth of the IP infrastructure, it is reasonable to expect
   that mobile and fixed Internet telephony will initially complement
   the 1G/2G mobile and PSTN services in the near future and will
   inevitably displace/replace them in a much longer term. Since SIP [1]
   is gaining acceptance as the signaling protocol of multimedia and
   Internet telephony, it is essential to develop a mechanism for
   supporting multimedia mobile applications in a SIP signaling and
   control environment.

   The key objectives of this document are to

   ** describe the frame work requirements for mobility management in
      general, as well as the mobility management functions and
      requirements in particular,

   ** identify open issues involved in supporting application of roaming
      users in a SIP signaling and control environment, and

   ** include the relevant issues in the agenda of the SIP WG and/or
      other appropriate WGs in the IETF.

   This document is organized as follows: Section 2 provides the overview



ITSUMO Group                                                    [Page 2]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


   of an end-to-end wireless/wireline IP infrastructure. In Section 3, we
   present the general system requirements and considerations for mobility
   management. Section 4 focuses on necessary functions for supporting
   mobility as well as their requirements. Section 5 identifies some of the
   open issues involved in supporting roaming users in a SIP environment,
   and Section 6 summarizes the document.

2. Architecture of an End-to-End Wireless/Wireline IP Infrastructure

   We envision that all services, real-time and non-real-time will
   eventually migrate onto an end-to-end wireless/wireline platform.
   The users have IP stationary and/or mobile appliances and use
   end-to-end IP transport and signaling/control from user terminal
   to user terminal including possible use of IP transport and
   control on the air interface.

   Figure 1 depicts the end-to-end signaling/control and transport
   platform of a wireless/wireline network. It comprises third
   generation (3G) IP access networks and a packet switched IP
   backbone network. The IP backbone network is an end-to-end
   wireline IP infrastructure that will comprise regional providers'
   wireline IP networks that are connected through the Internet. The
   3G wireless IP networks allow mobile stations (MSs) to access the
   wireline infrastructure. In order to support the needs of its users,
   a wireless access network interacts with the control entities of
   the end-to-end network.

   As shown in Figure 1, SIP [1] is the basis of the overall control
   architecture of the end-to-end wireline/wireless network. The
   overall control systems comprises SIP servers and agents, MAAAQ
   (mobility management, Authentication, Accounting and Qos management),
   and SIP registrars.  SIP provides connection management as well as
   means of interaction between users and network control system and
   interaction among network control entities. MAAAQ entities support
   mobility management, AAA, and QoS management functions for mobile users.
   These functional entities usually reside on the wireline backbone, and
   are part of the overall control system of the end-to-end platform.



          Visiting Network                           Home Network
      <-------------------->                    <-------------------->

        Visiting Registrar                          Home Registrar
          +----+                                       +----+
          | VR |                                       | HR |
          +----+                                       +----+
            |                                            |



ITSUMO Group                                                    [Page 3]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


            |                                            |
       +-----------+                                 +-----------+
       |  MAAAQ    |                                 |  MAAAQ    |
       +-----------+                                 +-----------+
       | SIP Server| <-----------------------------> | SIP Server|<....
       +-----------+                                 +-----------+     .
             |                                           |             .
          ___|___              _______                ___|___          .
         /       \            /       \              /       \         .
        /         \          /         \            /         \        .
       /Regional IP\________/  Internet \__________/Regional IP\       .
       \ Network   /        \           /          \ Network   /       .
        \         /          \         /            \         /        .
         \_______/            \_______/              \_______/         .
             |                                             |         SIP
             |                                             |           .
          ___|___                                       ___|___        .
         /       \                                     /       \       .
        /         \                                   /         \      .
       / 3G Access \                                 / 3G Acces  \     .
       \ Network   /                                 \ Network   /     .
        \         /                                  |\         /|     .
         \_______/                                   | \_______/ |     .
             |                                       |           |     .
             |                                       |           |     .
             |                                       |           |     .
             |                                       |           |     .
          +-----+                                 +-----+      +-----+..
          | MS  |                                 | MS  |      |  MS |
          +-----+                                 +-----+      +-----+

      Figure 1.  The end-to-end control and network architecture.

   All MSs and fixed hosts have SIP user agents that provide means of
   interactions with the SIP servers (i.e., proxy servers, redirect
   servers, and registrar) within the network.  In Figure 1, the SIP
   server entity of a regional IP network represents the set of SIP
   proxy and SIP redirect servers within the regional network perform
   the network control and signaling functions. Similarly, the registrar
   represents the server (or set of servers) that accepts (accept) SIP
   REGISTER requests and provides (provide) necessary functions, similar
   to those of the home/visiting location registries (HLR/VLR) in today's
   wireless telephony to roaming users. As Figure 1 shows the MAAAQ entity
   uses SIP features and capbilities to support roaming users.  The
   illustration of the MAAAQ entities and SIP server as a single module in
   Figure 1 should not be interpreted as a requirement for having a
   centralized SIP server or MAAAQ entity per regional network. Figure 1
   only shows the required functions, though each of the SIP and MAAAQ



ITSUMO Group                                                    [Page 4]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


   entities comprise a set of distributed agents. Similarly, the SIP
   registrars (i.e., HR and VR) may be implemented as either central or
   distributed databases.

   The remainder of this document focuses primarily on the requirements,
   functions, and issues that arise in supporting roaming users in such
   an IP wirless-wireline infrastructure.

3. Framework Requirements for Mobility Management

   In general, the mobility management scheme of wireless IP networks
   satisfies the following requirements [2, 6].

      I. It supports means of personal as well as terminal mobility,
         i.e., it allows users to access the network services
         anywhere using their own mobile terminal/station (referred to
         as the mobile station or simply MS, hereafter).

     II. It supports global roaming, i.e., it shall allow users
         to roam across different technology platforms, and across
         subnets within the same administrative domain as well as across
         subnets that belong to different administrative domains.

    III. It is wireless "technology-independent", i.e., it should
         remain independent of the underlying wireless technology.
         This requirement allows the ISPs and network operators to
         upgrade their sub-systems independently and build multi-vendor
         solutions. Furthermore, this requirement ensures that the
         mobility management scheme can be transported over all members
         of the IMT-2000 family which comprises several wireless
         technologies such as W-CDMA, TDMA, etc. [3, 4].

     IV. It supports both real-time and non-real-time multimedia
         services such as mobile telephony, mobile web access, and mobile
         data services in a way that their prices and performance are
         comparable to those of their counterparts in today's mobile
         voice and data services. In order to do so, the mobility
         management scheme should interact effectively with the QoS management
         and authetication, authorization, and authentitcation (AAA) schemes
         of the end-to-end network to verify the users' identities and rights,
         as well as to ensure that the QoS requirements of applications
         are satisfied.

      V. It transparently supports current TCP-based Internet application.
         It should support TCP as is without requiring any changes to TCP
         protocol or TCP-based applications, i.e., it should spoof/maintain
         constant end-points for TCP connections.




ITSUMO Group                                                    [Page 5]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


     VI. It allows a mobile station/user to decide whether it conveys its
         location to correspondent hosts or not. This requirement allows
         users to enhance their confidentiality and privacy, when necessary.

    VII. It supports multicast and anycast trees efficeinetly as mobile
         stations/users move around.

   VIII. Last but not least, it interworks smoothly with PSTN and today's
         1G/2G wireless telephony to facilitate interworking of new operators'
         all IP platforms with PSTN and the existing 1G/2G wireless telephony [5].


4. Mobility Management Functions and Requirements

   Simply speaking, a roaming MS should be able to receive (and send)
   calls/data from (and to) anyone in any place, and maintain its
   ongoing communications with others regardless of its point of
   attachment to the network.  In order to achieve this goal, the
   mobility management scheme shall support hand-off, registration,
   configuration, dynamic address binding, and location management
   whenever necessary. The remainder of this section describes these
   functions as well as their performance requirements in more detail.

4.1 Hand-off

   Hand-off (or handover) is a process that allows a established
   call/session to continue when a MS moves from one cell to another
   (intercell) or between radio channels in the same cell (intracell)
   without interruptions in the call/session. The hand-off process can
   be either hard or soft. In the hard hand-off the mobile receives and
   accepts only one radio signal from a radio channel or base station
   within a single cell.  As the mobile moves into a new cell, its signal
   is abruptly handed over from its current cell (or base station) to the
   new one rapidly in a few seconds.

   With soft hand-off the MS continues to receive and accept radio
   signals from the base stations within its previous as well as its new
   cell for a limited period of timer. Signal reception from the old base
   station ceases when the signal strength drops/reduces below a certain
   threshold. As its name indicates, soft hand-off smoothly transfers the
   MS's session from its old base station to the new one.  All third
   generation CDMA wireless technologies use soft hand-off. The soft
   hand-off process can take a relatively long period (i.e., several seconds),
   particularly, when it includes the entire process of pilot strength
   measurement, issuing of pilot strength measurement message (PSMM) on
   the uplink, and addition of new pilot to active set. In principle,
   soft hand-off is not always a transient process, and may take a long
   time depending on MS's request and requirements.



ITSUMO Group                                                    [Page 6]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


   In order to take advantage of the soft hand-off feature of the third
   generation CDMA wirless technologies in mobile IP packet networks,
   during the soft hand-off period, the packets which are destined for
   a MS shall be routed to both its previous and current locations.
   This routing of packets to the current and previous locations of a
   MS constitutes a logical/virtual soft hand-off at the IP layer.

   The hard hand-off process should take only a few second, while the soft
   hand-off process can take much longer (i.e., about several seconds).
   Nevertheless, in order to ensure the wireless "technology independence"
   requirement of mobility management schemes, we require a maximum acceptable
   hand-off time (MAHT) a few seconds (i.e., MAHT = 2-3 seconds). This
   requirement is acceptable for both hard and soft hand-off mechanisms,
   though it can be relieved significantly in the case of soft hand-off.


   We identify three levels of logical/virtual hand-off: cell, subnet, and
   domain.


   a. Cell hand-off (or micro-mobility): It allows a MS to move from a cell
      to another in a subnet within an administrative domain.

   b. Subnet hand-off (or macro-mobility): It allows a MS to move from a cell
      within a subnet to an adjacent cell within another subnet that belongs
      to the same administrative domain.

   c. Domain hand-off (or global mobility): It allows a MS to move from one
      subnet within an administrative domain to another in a different
      administrative domain.


In general, the cell hand-off is more frequent than subnet hand-off and subnet
   hand-off is more frequent than the domain hand-off. The hand-off process is
   built upon the registration, configuration, dynamic address binding, and
   location management functions. Hand-off process is transparent to users
   and satisfies the following requirements.


     i. All three hand-off processes ensure the integrity, privacy and
        confidentiality of users' information as well as prevent fraud and
        theft of service. They

         -  ensure the security of signaling (e.g., registration) messages to
            prevent eavesdropping and theft of users' data and service
            profiles as well as maintain confidentiality of users' locations,
            and




ITSUMO Group                                                    [Page 7]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


         -  perform the necessary AAA process to verify users' identities and
            their rights to requested resources, and ensure correct and
            non-repudiatable accounting, and

    ii. All three hand-off processes strive to maintain the QoS of the session
        as the MS roams around. For instance, they strive to

         a. minimize the loss of transient data during the hand-off, and

         b. satisfy the delay requirements of real-time applications as a
            MS roams around.

   iii. The domain hand-off latency should not exceed MAHT to ensure continuity
        of real-time sessions.

    iv. The subnet hand-off latency shall not exceed MAHT, though it should be
        much less than domain hand-off latency because it does not usually
        involve AAA process.

   A few points are worth noting. First, the domain hand-off process is
   functionally equivalent to the sum of subnet hand-off and AAA processes.

   Second, the domain hand-off latency is the sum of the registration,
   configuration, and address binding latencies, while location management
   process can be performed after (or concurrent with) the hand-off. Let
   us use a qualitative and intuitive discussion to estimate rough upper
   bounds of the registration and configuration latencies. Let us assume that
   processing delay is negligible, and the upper bound on the soft hand-off
   latency, MAHT is about 2-3 seconds.  The address binding latency is at
   most an end-to-end (source - destination - source) round trip queueing and
   propoagation delay. The round trip propagation delay for continental U.S.
   is about 50 ms (i.e., New Seattle - Miami - Seattle). Assuming an address
   binding delay of 1 second, we are left with less than 1-2 seconds
   for both registration and configuration delays. The goal is to get the
   confiuration latency down to millisecond (e.g., a few hundred milliseconds,
   and bounded mostly by the speed of the access link) [15].  Thus, with soft
   hand-off registration latency shall not exceed 1-2 seconds. The preceding
   back of the envelop calculation indicates that that registration and
   configuration should take roughly 1-2 seconds though thorough measurements
   are needed to establish precise upper bounds on the registration and
   configuration latencies.

   Third, in order to satisfy the "wireless-independence" and global roaming
   requirements, the hand-off processes minimize their reliance on the
   link layer.  To achieve this goal, the subnet and domain hand-off processes
   remain completely independent from the link layer, while the cell hand-off
   (i.e., micro-mobility) strives to minimize its dependence on the link layer
   specifications.



ITSUMO Group                                                    [Page 8]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


4.2 Registration

   Registration is a process by which a network becomes aware of the existence
   and the location of an MS and its associated user. When an MS becomes active
   (i.e., is turned on) in a network or roams into a new subnet or domain, it
   shall register with the network. This process comprises sending a
   registration request from the MS to the network, and performing an AAA
   (i.e., authentication, authorization, and accounting) process by the network,
   and sending appropriate responses to the MS as well as location management
   entities to ensure that the network is aware of MS's current location.
   There are two types of registration, complete and expedited (or partial).

   a. Complete Registration: This process occurs when a user turn on its MS
      or roams into a new administartive domain (i.e., during domain hand-off).
      In this case, the network shall perform AAA, and send appropriate
      responses to the MS and location management entities.

   b. Expedited/Partial Registration: This process is invoked when a user
      moves from one subnet to another within the same administrative domain
      (i.e., subnet hand-off). It does not include AAA process of complete
      registration, and its main objective is to keep the location information
      up to date.

   The complete registration process should not take more than 1-2 seconds
   to be performed. The expedited registration process usually takes much less
   than the complete registration process.

4.3 Configuration

   Configuration is a process by which a MS updates its IP address as it roams
   between subnets either within the same administrative domain or in different
   administrative domains. As an MS moves between subnets (either within the
   same domain or in different ones), it needs to acquire a new IP address,
   possibly new default gateway, subnet mask, etc. as well, and to reconfigure
   itself accordingly.

   The key requirements of the reconfiguration process are that it

   ** should not take more than a few hundred milliseconds to complete, and

   ** should update the DNS to reflect the current address to name and name
      to address mappings, if necessary.

   If the underlying wireless platform supports soft hand-off, the reconfiguration
   process can take more time. However, a few hundred milliseconds upper bound
   should be acceptable for both soft hand-off and hard hand-off.

4.4 Dynamic Address Binding



ITSUMO Group                                                    [Page 9]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


   Dynamic address binding is a process for allowing an MS to maintain a
   constant identifier regardless of its point of attachment to the network.
   Dynamic address binding

   ** allows a user to maintain a universal identifier (e.g., a SIP URL)
      regardless of its point of attachment to the network, and

   ** facilitates support of TCP-based applications by informing each endpoint
      about the current address of the other one.

   Needless to say that required signaling for dynamic address binding should
   be secure to ensure privacy and location confidentiality and protect users
   against fraud.

4.5 Location Management

   Location management is a process by which the network updates the location
   database and supports location/redirect services to authorized users and
   authorities. The location service is essential only for new inbound sessions.
   Key requirements of location management are accuracy, being up to date,
   and confidentiality of the location information. The location information

   ** should be up to date and accurate, e.g., the domain name service shall
      ensure correct name to address and/or address to name mapping as soon
      as possible, and

   ** should only be disclosed to authorized users and relevant authorities
      within the scope of the law.

4.6 Required Functions for Cell, Subnet, and Domain Hand-off

   Table 1 summarizes the functions that are needed for supporting each level
   of hand-off, cell, subnet and domain.

   -------------|--------------|---------------|-----------------|------------
   Hand-off type| Registration | Configuration | Address Binding | Location
                |              |               |                 | Management
   -------------|--------------|---------------|-----------------|------------
   Cell         |  NO          | NO            |  Yes            | Yes
   -------------|--------------|---------------|-----------------|------------
   Subnet       |  NO          | Yes           |  Yes            | Yes
   Intra-domain |              |               |                 |
   -------------|--------------|---------------|-----------------|------------
   Domain       |  Yes         | Yes           |  Yes            | Yes
   Inter-domain |              |               |                 |
   -------------|--------------|---------------|-----------------|------------

   Table 1. Required functions for supporting different levels of hand-off



ITSUMO Group                                                   [Page 10]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


5. Issues in Supporting Mobility in a SIP Environment

   Having described mobility management and its requirements, let us identify
   a preliminary list of open issues that arise in supporting these
   requirements in a SIP control environment for further study.

5.1 Supporting macro and global mobility for multimedia applications
    of roaming users

   In principle, mobile IP provides means of macro and global mobility for
   non-real-time services. It provides means of terminal mobility as well as
   dynamic address assignment using network access identifier (NAI). However,
   mobile IP by itself does not provide means of personal mobility and
   location service. Furthermore, the impact of the triangular routing (in
   classic mobile IP) and route optimization scheme on the QoS requirements
   of real-time services requires further study. Different approaches for
   either coexistence of SIP and mobile IP [10, 14], or the development of
   a new SIP based mobility management protocol [11] have been proposed.
   However, the interaction of mobile IP with and its impact on the SIP
   signaling scheme of real-time services requires further study to determine
   the best approach for combining the salient features of mobile IP terminal
   mobility with those of the SIP personal mobility. Such an approach should

   ** spoof constant endpoints for TCP connections and support TCP as is without
      any modification to TCP protocol or TCP-based applications, and

   ** require RTP [16] applications to accept packets with the same
      synchronization source (SSRC) but different source IP address.

5.2 Complete registration in less than a few seconds

   Registration in a mobile environment has two objectives, informing
   the network about the MS (or user) and its location, and verifying
   the MS identity and services that the MS is entitled to. Using SIP
   REGISTER method, one can adequately achieve the former in the MS's
   home network. However, the latter is an essential required function
   that allows MSs to roam among different administrative domains. One
   can conceive several alternatives for performing complete registration.

   One alternative is that the MS utilizes a separate protocol such as
   DRCP [12] or mobile IP [10] to register with the network, and then
   uses the SIP REGISTER method to register with a SIP registrar that
   provides location service as well. In this case, the registration
   process places no additional requirements on SIP.

   Another alternative is that the registration process is done via SIP
   and SIP registrars of different domain interact with one another to
   verify a user's identity and rights using an AAA mechanism and



ITSUMO Group                                                   [Page 11]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


   acknowledge or deny the registration. In this case, SIP registrars
   shall be able to utilize/interact with an AAA scheme to adequately
   perform mobile registration. Moreover, though NOT necessarily a SIP
   issue, it essential to have a fast and scalable AAA mechanism for wide
   area networks that can authenticate and authorize a MS and its user in
   less than a few seconds. See McAuley, et-al. [13] for further details
   on AAA requirements and constraints.

5.3 Reconfiguration in fractions of a second

   This requirement is an important one. It does not seem to impose any
   requirements on SIP, however, it places significant requirements on
   DHCP (see McAuley, et al. [15] for further details). As the MS roams
   into a new subnet or a new administrative domain, it may need to acquire
   a new address before being able to register. In order to do so, the MS
   interacts with DHCP [7] to obtain a new IP address, and reconfigure
   itself. Currently, it takes DHCP several seconds to reconfigure a host. This
   latency is usually too much for mobile users. Different schemes such as
   fast DHCP that does not perform conflict resolution, and or novel schemes
   such as dynamic registration and configuration (DRCP) [12] have been
   proposed to reduce the reconfiguration delay of a MS. Moreover, DHCP
   may need to interact with DNS and update it dynamically so that the name
   to address mappings remain current. Further study is needed to arrive at
   appropriate solutions for these issues.

5.4 Providing location service

   As the MS roams around it should update its location so that authorized
   users can direct their new calls/sessions the MS's current location. Among
   the approaches for providing location service are

    a. the dynamic update of the DNS, and

    b. the development of a brand new protocol that allows applications
       to use SIP registrar for name to address and address to name
       mappings.

   Neither of these approaches seems to have any impact on SIP specifications,
   though the latter should be built upon the SIP specifications and use
   SIP methods.

5.5 Supporting the soft hand-off procedure

   The third generation CDMA wireless technologies all support soft hand-off
   procedure which allows a roaming MS to receive and accept signals from
   both its new base station as well the old one simultaneously during the
   soft hand-off period (about several seconds). In order to utilize this
   feature the macro and global mobility scheme shall emulate a virtual soft



ITSUMO Group                                                   [Page 12]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


   hand-off at the IP layer via forwarding the session's packets to the old
   as well as the new location of the MS during the soft hand-off. In order
   to support virtual soft hand-off, SIP shall be able to extend the ongoing
   session to the new location of the MS, and drop the old location after a
   limited period of time. The exact mechanism for realizing virtual soft
   hand-off requires further study.

5.6 Providing secure signaling for mobile users

   Due to the ease of "wire-tapping" in a wireless environment, the signaling
   and user data should be encrypted to ensure privacy and confidentiality of
   users and protect them against fraud and theft of service. SIP messages can
   already be encrypted. Nevertheless, the SIP WG has chartered a task force to
   identify and address issues (e.g., key management) that arise in enhancing
   SIP security mechanisms. The SIP security task force should address this
   problem in the context of wireline as well as wireless networks.

6. Summary and Conclusions

   This document focused on supporting mobility in a SIP signaling and
   control environement. It identified the functions, requirements, and
   open issues so that they are included in the agenda of the SIP WG as
   well as other appropriate WGs of IETF in a timely manner.


7. Acknowledgments

   The authors wish to acknowledge the contributions of other members of
   the ITSUMO(TM) team from Telcordia (P. Agrawal, , S. Das, D.
   Famolari, A. McAuley, P. Ramanathan, and R. Wolff) and Toshiba
   America Research Incorporated (T. Kodama). We also thank P. Zablocky
   and J. C. Liberti from Telcordia for helpfull discussions on soft
   hand-off procedures.  Special thanks are due to Glenn Morrow from
   Nortel Networks for his comments on version 00 of this document.

   (TM): ITSUMO (Internet Technology Supporting Universal Mobile
   Operation) is a trademark of Telcordia. It is a joint research
   project of Telcordia Technologies and Toshiba America Research Inc.
   (TARI). It envisions an end-to-end wireless/wireline IP platform for
   supporting real-time and non-real-time multimedia services in the
   future.  Its goal is to use IP and third generation wireless
   technologies to design a wireless platform that allows mobile users
   to access multimedia services on a next generation Internet. In
   Japanese, ITSUMO means anytime, all the time.

8. References

   1. M. Handly, H. Schulzrinne, E. Schooler, and J. Rosenberge,



ITSUMO Group                                                   [Page 13]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


      "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   2. ITSUMO Group, "Benchmarking of ITSUMO's All IP Wireless
       Architecture", mwif2000.028, January 28, 2000.

   3. ITU-R Rec. M.687-2, "International Mobile Telecommunications-2000
      (IMT-2000)", 1997.

   4. ITU-R Rec. M.817, "International Mobile Telecommunications-2000
      (IMT-2000), Network Architectures", 1992.

   5. ITSUMO Group, "Evolution of Wireless Telephony towards Voice over
      3G-IP", 3GPP2- P00-19990824-010, August 23, 1999.

   6. E. Gustafson, A.Johnson, E. Hubbard, J. Malmkvist, and A. Roos,
      "Requirements on Mobile IP from a Cellular Perspective", , work in progress,
      June 1999.

   7. R. Droms, "Dynamic Host Reconfiguration Protocol", RFC 2131,
      March 1997.

   8. C. Perkins, "IP Mobility Support", RFC 2002, October 1996.

   9. C. Perkins, and D. B. Johnson, "Route Optimization in Mobile IP",
       Internet Draft, ,
       February 25, 1999.

   10. P. R. Calhoun, and J. Kempf, " Mobility Management and
       Authentication in an All-IP Network", mwif00.009, January
       17, 2000.

   11. F. Vakil, A. Dutta, J-C. Chen, S. Baba, and Y. Shobatake, "Host
       Mobility Management Protocol: Extending SIP to 3G-IP Networks",
       Internet Draft, , work in progress,
       October 1999.

   12. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Dynamic
       Registration and Configuration Protocol for Mobile Hosts",
       Internet Draft, , work in progresss,
       October 1999.

   13. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Authentication,
       Authorization, and Accounting Requirements for Roaming Nodes
       using DHCP", Internet Draft, , work in progress, March 2000.

   14. E. Wedlund, and H. Schulzrinne, "Mobility Support using SIP



ITSUMO Group                                                   [Page 14]

Internet-Draft  Mobility Management in a SIP Environment      March 2000


       and RTP", ACM Multimedia Workshop, Seattle, August 1999.

   15. A. McAuley, S. Das, S. Baba, and Y. Shobatake, "Requirements for
       Extending DHCP into New Environments", Internet Draft, , work in progress,
       March 2000.

   16. H. Schulzrinne, S. Casner, R. Fredrick, and V. Jacobson, "RTP: A
       Transport Protocol for Real-Time Applications", RFC 1889, January
       1996.

9. Authors' Addresses

   Faramak Vakil
   Telcordia Technologies, Rm 1C-135B
   445 South Street, Morristown,  NJ  07960-6438
   farm@research.telcordia.com

   Ashutosh Dutta
   Telcordia Technologies, Rm 1C-227B
   445 South Street, Morristown,  NJ  07960-6438
   adutta@research.telcordia.com

   Jyh-Cheng Chen
   Telcordia Technologies, Rm 1G-236B
   445 South Street, Morristown,  NJ  07960-6438
   jcchen@research.telcordia.com

   Shinichi Baba
   Toshiba America Research Inc. (TARI)
   P. O. BOX 136
   Convent Station, NJ 07961-0136
   sbaba@tari.toshiba.com

   Yasuro Shobatake
   Toshiba America Research Inc. (TARI)
   P. O. BOX 136
   Convent Station, NJ 07961-0136
   yasuro.shobatake@toshiba.co.jp

   Henning Schulzrinne
   schulzrinne@cs.coumbia.edu
   Department of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY, 10027





ITSUMO Group                                                   [Page 15]

--------------46A0FC4882A58ED2814B335F--




From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 24 18:07:56 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10910
	for ; Fri, 24 Mar 2000 18:07:55 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 209D352D5; Fri, 24 Mar 2000 18:05:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9350952DB; Fri, 24 Mar 2000 18:05:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 6DDBD52D5
	for ; Fri, 24 Mar 2000 18:05:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 24 18:04:18 EST 2000
Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Fri Mar 24 18:04:18 EST 2000
Received: from vovida.com (pool0842.cvx20-bradley.dialup.earthlink.net [209.179.253.77])
	by repulse.cnchost.com
	id SAA24460; Fri, 24 Mar 2000 18:03:47 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38DC10F9.B38C15CA@vovida.com>
Date: Fri, 24 Mar 2000 17:06:02 -0800
From: Krishan Veer 
Organization: Vovida Networks
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Subject: Reg: ProxyAuthorization
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi everyone!

I was trying to figure out can ProxyAuthorization be Legally in General
Header Field /serve both request and response??
can Proxy Authorization can be used in Status Msg. if yes ? then what
should be its legal  usage it sould sent back the value in status msg
or boolean flag in case of 1XX/3XX.

--
Krishan veer
Software Engineer
http://www.vovida.com




From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 24 22:54:09 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21862
	for ; Fri, 24 Mar 2000 22:54:09 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 5DD0652D5; Fri, 24 Mar 2000 22:51:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id CB7A452DA; Fri, 24 Mar 2000 22:51:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id E951452D5
	for ; Fri, 24 Mar 2000 22:51:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 24 22:50:45 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Fri Mar 24 22:50:45 EST 2000
Received: from dynamicsoft.com (1Cust117.tnt1.adl1.da.uu.net [210.84.192.117])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA14920;
	Fri, 24 Mar 2000 22:51:52 -0500 (EST)
Message-ID: <38DC3940.E8C68AD0@dynamicsoft.com>
Date: Fri, 24 Mar 2000 22:57:52 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Krishan Veer 
Cc: sip 
Subject: Re: Reg: ProxyAuthorization
References: <38DC10F9.B38C15CA@vovida.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

No, Proxy-Authorization is a request header only. There is no way to
allow proxies to challenge the UAS which would be the only reason for
including it in a response. Not sure what this is useful for, anyway...

-Jonathan R.

Krishan Veer wrote:
> 
> Hi everyone!
> 
> I was trying to figure out can ProxyAuthorization be Legally in General
> Header Field /serve both request and response??
> can Proxy Authorization can be used in Status Msg. if yes ? then what
> should be its legal  usage it sould sent back the value in status msg
> or boolean flag in case of 1XX/3XX.
> 
> --
> Krishan veer
> Software Engineer
> http://www.vovida.com

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Sat Mar 25 00:04:03 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17492
	for ; Sat, 25 Mar 2000 00:04:02 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 36BD552C4; Sat, 25 Mar 2000 00:01:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A2F7F52C8; Sat, 25 Mar 2000 00:01:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 744CF52C4
	for ; Sat, 25 Mar 2000 00:01:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sat Mar 25 00:00:08 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Sat Mar 25 00:00:07 EST 2000
Received: from dynamicsoft.com (1Cust117.tnt1.adl1.da.uu.net [210.84.192.117])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA14937;
	Sat, 25 Mar 2000 00:01:11 -0500 (EST)
Message-ID: <38DC497F.79FA6AE4@dynamicsoft.com>
Date: Sat, 25 Mar 2000 00:07:11 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" 
Cc: "'sip@lists.research.bell-labs.com'" 
Subject: Re: SIP Request Glare.
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Fairlie-Cuninghame, Robert" wrote:
> 
> ---
> Firstly concerning, request ordering and pending requests: Does order
> consistency condition extend to other methods, such as glare between
> METHOD-INFO & INFO-INFO request for example ? If not, then INFO and INVITE
> methods must be able execute independently (that is, you could have multiple
> active requests: an INVITE and an INFO, or two INFOs). What is the correct
> handling of this situation ?

The ordering is only important if the messages have an effect on shared
state. By its definition, INFO cannot affect call or session state.
Therefore, I believe it is safe to process an incoming INFO whilst
processing an outgoing INFO or INVITE or anything else. Among the set of
existing methods, I believe only INVITE has this problem.


Regarding the glare issue, Kelly later writes:
> We've introduced an alternate proposal in a recent I-D (see, in particular,
> section 7 of http://www.ietf.org/internet-drafts/draft-mark-sip-dmcs-00.txt)
> that attempts to address the problem.  Loosely, our proposal entails
> comparing the URIs used in the To and From fields of the INVITEs as the
> basis for comparison.  The party whose URI is lesser is designated the
> victor when crossing INVITEs arise.

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 w/ a 200 OK. Then, A gets the non-500 response from B. Now A
is really confused.

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

I think this can be fixed if each side includes, in a re-INVITE, the
CSeq of the request last received from the other party (or -1 or
something if it hasn't gotten one yet). This will allow each side to
determine, when it receives a reinvite while reinviting, whether the
reinvite it sent has been received and responded to by the other side.
This requires an extension, and its not backwards compatible, which is
kind of yucky. Below is an alternate solution.




> 
> Now regarding glare resolution: Is the proposed glare resolution solution
> acceptable in a telephony environment? The granularity of Retry-After is in
> seconds. So to have a reasonable chance of not colliding again you must make
> the random range large; yet it is unacceptable to have a delay any more than
> a second or two in most telephony applications. For instance if the random
> range of Retry-After is up to three seconds, then this only allows three
> random outcomes => leading to a roughly 33% chance of re-collision.
> Additionally, even for this small value of Retry-After there is roughly only
> a 66% chance that a request will commence within 2 seconds (which is still
> unacceptable in many situations). Whether or not you have a small or large
> random range for Retry-After doesn't help because of the lack of random
> granularity.

Well, how about we add random granularity? We could simply say that both
sides should retry within a random time distributed between 0 and some
number. This number has to be chosen large enough to reduce the
probability of collision again, but small enough to make the re-invite
resolve quickly. Glare happens again if both sides choose a number
within 1/2 RTT of each other. Lets say 1/2 RTT = 50ms. If we want the
re-glare case to happen with < 5% probability, choosing the number
randomly between 0 and 1 second should work.

This solution doesn't require an extension. Its not as fast as above,
but its not as complex.


-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Sat Mar 25 02:58:01 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03002
	for ; Sat, 25 Mar 2000 02:58:01 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id DE8E752DA; Sat, 25 Mar 2000 02:55:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 3F2CC52DB; Sat, 25 Mar 2000 02:55:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 8EA3F52DA
	for ; Sat, 25 Mar 2000 02:55:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sat Mar 25 02:53:33 EST 2000
Received: from prserv.net ([32.97.166.31]) by dusty; Sat Mar 25 02:53:32 EST 2000
Received: from cs.columbia.edu ([139.92.185.119])
          by prserv.net (out1) with SMTP
          id <2000032507531925200a16p4e>; Sat, 25 Mar 2000 07:53:21 +0000
Message-ID: <38DC6E4B.4D05CADC@cs.columbia.edu>
Date: Sat, 25 Mar 2000 02:44:11 -0500
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen 
Cc: Jonathan Rosenberg ,
        SIP 
Subject: Re: Session timer comments
References: <38CCEB34.E5CE4B41@hplb.hpl.hp.com> <38D873C1.D2797AA7@dynamicsoft.com> <38D8B67C.E4A14A16@hplb.hpl.hp.com> <38D8DD11.1809CF54@cs.columbia.edu> <38D8E2A4.FD004D4C@hplb.hpl.hp.com> <38DB0555.1EEEDF10@dynamicsoft.com> <38DBB9A7.9B72DFD@hplb.hpl.hp.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

My general inclination is to allow implementations latitude to
accomodate their own specific requirements, as long this doesn't
interfere with other compliant implementations. In this case, whether to
accept a tagged (re)INVITE can be completely up to the UAS. In general,
it may be difficult to do this (e.g., because of connection-oriented
media streams), but since the UAS clearly indicates its reaction, I
don't see the need to disallow either accepting or rejecting
connections. Outlining the trade-offs is obviously helpful.

Such flexibility is particularly important since we don't want to
restrict SIP to just setting up 'traditional' phone calls. As a somewhat
contrived example, imagine some kind of RTP-based monitoring application
in a system with a watchdog timer (that reboots the system if hung). In
that case, having a periodic refresh of the session is appropriate and
contributes to overall system reliability.





From owner-sip-outgoing@lists.research.bell-labs.com  Sat Mar 25 12:56:14 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07651
	for ; Sat, 25 Mar 2000 12:56:14 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 29B4452D6; Sat, 25 Mar 2000 12:53:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D0C7652DE; Sat, 25 Mar 2000 12:53:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 7F9A352D6
	for ; Sat, 25 Mar 2000 12:53:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sat Mar 25 12:52:03 EST 2000
Received: from mail.pingtel.com ([216.91.1.131]) by dusty; Sat Mar 25 12:52:02 EST 2000
Received: from stbarth.pingtel.com (cdhcp120.pingtel.com [10.1.1.120])
	by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id MAA25448;
	Sat, 25 Mar 2000 12:35:12 -0500
Message-Id: <4.3.2.20000325121613.00bf43c0@mail.pingtel.com>
X-Sender: jbatson@mail.pingtel.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Sat, 25 Mar 2000 12:48:23 -0500
To: sip@lists.research.bell-labs.com
From: Jay Batson 
Subject: Re: comments on draft-rosenberg-sip-3pcc-00.txt
Cc: schulzrinne@cs.columbia.edu,
        "Jonathan Rosenberg" , archow@hss.hns.com
In-Reply-To: <38D9A88B.12835052@dynamicsoft.com>
References: <652568AB.0017A582.00@sampark.hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


> > Infact, if you really want to do it that way, why couldnt a controller
> > simply send an INFO to A - telling it that it needs to contct B ?
>
>We have discussed that as well (OPTIONS with Also was the initial
>proposal). It suffers from the problem that there isn't much feedback on
>call state to the controller, and no subsequent control is possible.
>Thus, it doesn't solve much.

Jonathan --

Your 3pcc draft is in fact a nice bit of work.  It *does* solve the problem 
for "controller-in-charge" designs.

Arjun's point, however, is valid.  There are going to be plenty of 
circumstances and designs where the central point merely wants to trigger 
-- not "control" a call.  His INFO approach seems much lighter weight and 
appropriate for the task.

Dan P. (our resident SIP expert) isn't here for me to make sure I'm not 
making a fool of myself.... ;-)  But I can imagine that Arjun's method 
would be just *fine* as a way to support 3rd party call control for use in 
"click to dial" from a desktop PIM (e.g. Outlook).  Desktop software could 
simply send an INFO message (containing the SIP URL to be dialed) to a User 
Agent, and then the User Agent does its "normal" thing.  The desktop 
software doesn't need to be "in charge" of the call -- just triggering the 
endpoint to do its normal thing.  In another example, Outlook could send 
similar INFO messages to multiple User Agents to trigger all of them to 
dial a SIP URL for a SIP-enabled conference bridge.

I would be interested in knowing whether Arjun's approach can be done 
without any new syntax/verbs/....  If so, I think it would be appropriate 
to reflect an example in the draft that *isn't* based on a the "controller 
in charge" model.  I know the *point* here is 3rd party call control, but 
his point is that there are varying amounts of 3rd party control 
required.  I think it's appropriate to have the "experts" provide examples 
in the draft that indicate lighter weight methods like Arjun's for those 
who don't want to implement full, state-sensitive, ..., 3rd party control 
for something as basic as triggering a call.

Cheers
-jb






From owner-sip-outgoing@lists.research.bell-labs.com  Sat Mar 25 17:44:04 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09846
	for ; Sat, 25 Mar 2000 17:44:03 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id B213F52DB; Sat, 25 Mar 2000 17:41:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 2B46A52E0; Sat, 25 Mar 2000 17:41:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id CB59552DB
	for ; Sat, 25 Mar 2000 17:41:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Mar 25 17:41:00 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Sat Mar 25 17:41:00 EST 2000
Received: from dynamicsoft.com (1Cust99.tnt1.adl1.da.uu.net [210.84.192.99])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA15169;
	Sat, 25 Mar 2000 17:42:06 -0500 (EST)
Message-ID: <38DD422B.A7C0975A@dynamicsoft.com>
Date: Sat, 25 Mar 2000 17:48:11 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jay Batson 
Cc: sip@lists.research.bell-labs.com, schulzrinne@cs.columbia.edu,
        archow@hss.hns.com
Subject: Re: comments on draft-rosenberg-sip-3pcc-00.txt
References: <652568AB.0017A582.00@sampark.hss.hns.com> <4.3.2.20000325121613.00bf43c0@mail.pingtel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Jay Batson wrote:
> 
> Arjun's point, however, is valid.  There are going to be plenty of
> circumstances and designs where the central point merely wants to trigger
> -- not "control" a call.  His INFO approach seems much lighter weight and
> appropriate for the task.

I wasn't arguing that the 3pcc approach is the only way. I was only
pointing out that I suspected many other applications of 3rd party call
control would need some sort of feedback after the initial "please call
Joe" message. Certainly there are some that don't (you do point out an
example below). I'd like to see how long that list is. I have quite a
long list for 3pcc.

> 
> Dan P. (our resident SIP expert) isn't here for me to make sure I'm not
> making a fool of myself.... ;-)  But I can imagine that Arjun's method
> would be just *fine* as a way to support 3rd party call control for use in
> "click to dial" from a desktop PIM (e.g. Outlook).  Desktop software could
> simply send an INFO message (containing the SIP URL to be dialed) to a User
> Agent, and then the User Agent does its "normal" thing.  The desktop
> software doesn't need to be "in charge" of the call -- just triggering the
> endpoint to do its normal thing.  In another example, Outlook could send
> similar INFO messages to multiple User Agents to trigger all of them to
> dial a SIP URL for a SIP-enabled conference bridge.

Actually, the best way to do this is, rather than INFO or OPTIONS, is
the new TRANSFER (or PLEASE-INVITE as was suggested), as it is basically
exactly this function. Overloading these with something new is probably
not a good idea, as its hard to know, when you get an INFO or OPTIONS,
what are the things you actually need to do.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Sun Mar 26 20:18:40 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29151
	for ; Sun, 26 Mar 2000 20:18:40 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id F35BB52C8; Sun, 26 Mar 2000 18:29:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 61A8A52DC; Sun, 26 Mar 2000 18:29:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 6564B52C8
	for ; Sun, 26 Mar 2000 18:29:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Mar 26 18:28:48 EST 2000
Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Sun Mar 26 18:28:47 EST 2000
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FS100K1XYJYQP@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Sun, 26 Mar 2000 23:28:46 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FS100201YJY6Y@dgismtp01.wcomnet.com>;
 Sun, 26 Mar 2000 23:28:46 +0000 (GMT)
Received: from omzmta04.mcit.com ([166.37.214.10])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FS10020HYJX3Y@dgismtp01.wcomnet.com>; Sun,
 26 Mar 2000 23:28:46 +0000 (GMT)
Received: from sipdev4 ([166.44.60.34])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000326232845.HULF23055@sipdev4>; Sun,
 26 Mar 2000 23:28:45 +0000
Date: Thu, 23 Mar 2000 10:15:56 -0600
From: Robert Sparks 
Subject: RE: Update of 'Contact' address
In-reply-to: <38CF4F52.D5A8E385@dynamicsoft.com>
To: "'Jonathan Rosenberg'" ,
        "'Ravandhu Hariram'" 
Cc: sip@lists.research.bell-labs.com
Reply-To: Robert.Sparks@wcom.com
Message-id: <000001bf977a$4d3841c0$a9c0d0a9@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 8BIT


Jonathan Rosenberg wrote:
> >
> > After a call is fully connected between two user agents, if
> one user agent sends
> > a new INVITE request with a different 'Contact' address,
> should the receiving
> > user agent update its 'Route' header with this modified
> 'Contact' address?
>
> I think so. There are a few applications of this, including
> mobility and
> a few call services. Note, however, that updating of the
> Route with new
> Record-Route headers is different. RFC2543 forbids (I think) insertion
> of Record-Route headers when a Route is already there.

That restriction has been removed in the bis draft. In fact, the
new language

  "Note that proxy servers have to add Record-Route headers to each
   request as long as they want to be “visited” by the next request
   for the call leg."

can (and I argue should) be interpreted to mean that if a proxy
wants to stay in the path, it should add a Record-Route to
every request. In other words, the effect of Record-Route
is to ensure that the _next_ request from any participant comes
through this proxy.

RjS




From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 02:08:26 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03745
	for ; Mon, 27 Mar 2000 02:08:26 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 2D58952AB; Mon, 27 Mar 2000 02:05:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 94E6F52BB; Mon, 27 Mar 2000 02:05:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 472B852AB
	for ; Mon, 27 Mar 2000 02:05:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 27 02:04:04 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon Mar 27 02:04:04 EST 2000
Received: from dynamicsoft.com (dhcp-192-171.ietf.connect.com.au [169.208.192.171])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA15529;
	Mon, 27 Mar 2000 02:05:02 -0500 (EST)
Message-ID: <38DF0991.E522806B@dynamicsoft.com>
Date: Mon, 27 Mar 2000 02:11:13 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com, sip-h323@egroups.com,
        "Bradner, Scott" 
Subject: SIP and H.323 Interworking
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Folks,

As many of you may know, the conclusion of the SIP-H323 BoF today at
IETF was that there was not sufficient consensus for a *standards track*
rfc, and there was not sufficient consensus to work to occur in a
dedicated working group. From talking to people after the meeting, this
seems to have resulted in the impression that there is no interest or
value in Informational RFCs documenting the interworking process.

This is simply not true.

I, and many others, see much value in informational documents which
describe experience and collected expertise in how to do the
interworking. As a result, the SIP working group, with the approval and
support of our area director (AD),  will be hosting a task force
targeted at generation of informational RFC on SIP to H.323
interworking. This task force will continue to use the existing list,
sip-h323@egroups.com. People working on these documents should feel free
to bring up questions and issues on the main SIP list
(sip@lists.research.bell-labs.com) in order to facilitate their work.

Should any issues arise during this work which might neccessitate
revisiting the need for standards track work on SIP-H.323 interworking,
the ADs have indicated that a new BoF could be scheduled to discuss
them.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 05:10:04 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13726
	for ; Mon, 27 Mar 2000 05:10:02 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 0F6C152B6; Mon, 27 Mar 2000 05:07:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5948E52C4; Mon, 27 Mar 2000 05:07:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id E33DF52B6
	for ; Mon, 27 Mar 2000 05:07:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 05:06:59 EST 2000
Received: from exchangesvr.nuera.com ([204.216.240.124]) by dusty; Mon Mar 27 05:06:58 EST 2000
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 27 Mar 2000 02:07:04 -0800
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Jonathan Rosenberg'" ,
        "Fairlie-Cuninghame, Robert" 
Cc: "'sip@lists.research.bell-labs.com'" 
Subject: RE: SIP Request Glare.
Date: Mon, 27 Mar 2000 02:06:57 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA13726


> Well, how about we add random granularity? We could simply 
> say that both
> sides should retry within a random time distributed between 0 and some
> number. This number has to be chosen large enough to reduce the
> probability of collision again, but small enough to make the re-invite
> resolve quickly. Glare happens again if both sides choose a number
> within 1/2 RTT of each other. Lets say 1/2 RTT = 50ms. If we want the
> re-glare case to happen with < 5% probability, choosing the number
> randomly between 0 and 1 second should work.
> 
> This solution doesn't require an extension. Its not as fast as above,
> but its not as complex.
> 
That sounds reasonable but the clients must be able to differentiate this
glare situation from a normal 500 server overload response. Are you
proposing to send a "Retry-After: 0" or "Retry-After: 1" to indicate that
the client should retry after a small random delay? This scheme would still
require the clients to understand the "extension".

Maybe my math's is wrong but for RTT=100ms with a random retransmit range of
0-1 second isn't the chance of recollision equal to (0.95 * 100ms) + (0.05 *
(0.75 * 100ms)) = 8.75%. 

Is this solution acceptable for connections where the RTT is larger?
Consider a ½ RTT of 150 ms which is a quite noticeable but  tolerable delay
for voice media, however, the actual SIP RTT may be quite larger than the
media path. Now, if we chose 1 second for the random retransmit range I
believe this gives a chance of recollision of around 28%.  500ms RTT -> ~44%
(if my maths is correct). Loaded proxies and the like could conceivably
create an even longer SIP RTT, no ? 

Including the Retry-Resolve header separately and additionally to the
Retry-After means that a client which does not understand the former can
simply use the latter (and also differentiates glare from normal 500 server
internal errors). 
Can you see any flaws in the following scheme: After sending a 500 response
with Retry-After _and_ Retry-Resolve header, the client waits for a 500
response. If the inbound 500 response 
-	does contain a Retry-Resolve header
-	and the reverse CSeq in the Retry-Resolve matches the outbound
glaring request (see below) 
-	and the received Retry-Resolve random discriminator value is smaller
than the outbound value
then the response is immediately retransmitted; or otherwise the client
waits the full Retry-After duration before retransmitting (or terminates the
session).

I agree that the Retry-Resolve header needs to include the reverse glaring
request Cseq to eliminate certain race conditions (as you described).

For example: "Retry-Resolve:"  
. 

Can you see any holes in this scheme? Does this sound too complex or
incompatible with the current scheme? Is it worth it ? I believe that the
existence of methods to _robustly_ resolve problems such as glare are
important for overall confidence in a protocol - even if glare is normally
deemed an unlikely event.

Regards,

Robert.



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 07:48:08 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14177
	for ; Mon, 27 Mar 2000 07:48:08 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3C49052BB; Mon, 27 Mar 2000 07:45:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A789152C8; Mon, 27 Mar 2000 07:45:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 73DC552BB
	for ; Mon, 27 Mar 2000 07:45:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 07:44:06 EST 2000
Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by dusty; Mon Mar 27 07:44:04 EST 2000
Received: from static-240-16.ietf.connect.com.au by bells.cs.ucl.ac.uk 
          with Internet SMTP id ;
          Mon, 27 Mar 2000 13:43:58 +0100
Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) 
          by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id NAA00690;
          Mon, 27 Mar 2000 13:46:07 +0100
Message-Id: <200003271246.NAA00690@csperkins.demon.co.uk>
To: "Fairlie-Cuninghame, Robert" 
Cc: Kimmo.Rantanen@lmf.ericsson.se, sip@lists.research.bell-labs.com
Subject: Re: Question on RTP
In-Reply-To: Message from "Fairlie-Cuninghame, Robert"  of "Tue, 21 Mar 2000 01:37:13 -0800." 
Date: Mon, 27 Mar 2000 22:16:07 +0930
From: Colin Perkins 
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

--> "Fairlie-Cuninghame, Robert" writes:
>		--> Kimmo.Rantanen@lmf.ericsson.se writes:
>		>I like to add one more question:
>		>Is it absolutely necessary that both direction use the same
>type of
>		>codec ?
>
>		No.
>		
>		This is rather undesirable for vocoders or implementations
>employing advanced echo cancellation, intelligent jitter buffer management
>or a host of other DSP or voice-related properties.
>
>		From my reading of the RFC, it is also equally possible for
>either side to chop-and-change between vocoders at any point in time
>(without SIP message exchange). Supporting this mixing and splicing of
>vocoders significantly complicates the playback engine - the ability will
>most likely be unsupported on simpler implementations or at best may cause
>small audio glitches.
...
>		How have other people tackled this problem ? Are there any
>drafts or FAQ on these subjects. 

The RTP specification is written in such a manner that changing the codec
on the fly is acceptable behaviour, and is something an implementation
should be robust to. That said, I'd expect this is an unusual event, so a
small audio glitch is unlikely to be a problem when it occurs.

Colin



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 17:02:20 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25299
	for ; Mon, 27 Mar 2000 17:02:20 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3BB9752D6; Mon, 27 Mar 2000 16:59:33 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A948352C8; Mon, 27 Mar 2000 16:59:32 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id ABCE752D6
	for ; Mon, 27 Mar 2000 16:59:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 27 16:59:03 EST 2000
Received: from grimy.research.bell-labs.com ([204.178.16.57]) by dusty; Mon Mar 27 16:59:02 EST 2000
Received: from ckmso1.proxy.att.com ([12.20.58.69]) by grimy; Mon Mar 27 16:57:05 EST 2000
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id QAA18725;
	Mon, 27 Mar 2000 16:54:59 -0500 (EST)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id QAA19382; Mon, 27 Mar 2000 16:54:11 -0500 (EST)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 27 Mar 2000 16:54:58 -0500
Message-ID: 
From: "Roy, Radhika R, ALARC" 
To: Jonathan Rosenberg ,
        sip@lists.research.bell-labs.com, sip-h323@egroups.com,
        "Bradner, Scott" 
Subject: RE: SIP and H.323 Interworking
Date: Mon, 27 Mar 2000 16:54:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Hi, Everyone:

We have been pleased to see the clarification provided by Jonathan
Rosenberg, SIP WG Chair. Now we have the opportunity to proceed with our
SIP-H.323 Interworking work as follows:

1. A task force under SIP working group targeted at generation of
informational RFC.
2. Should it appear that we need to follow the standard track for the for
the SIP-H.323 interworking in the future, we can arrange another BOF with
the approval of the AD.

Now we have the clear direction to proceed with our work. Let us finish our
work as per schedule presented in yesterday's BOF.

Best regards,
Radhika R. Roy
AT&T
200 Laurel Ave S. Middletown, NJ 07748, USA
+1 732 420 1580
rrroy@att.com

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, March 27, 2000 2:11 AM
To: sip@lists.research.bell-labs.com; sip-h323@egroups.com; Bradner,
Scott
Subject: SIP and H.323 Interworking


Folks,

As many of you may know, the conclusion of the SIP-H323 BoF today at
IETF was that there was not sufficient consensus for a *standards track*
rfc, and there was not sufficient consensus to work to occur in a
dedicated working group. From talking to people after the meeting, this
seems to have resulted in the impression that there is no interest or
value in Informational RFCs documenting the interworking process.

This is simply not true.

I, and many others, see much value in informational documents which
describe experience and collected expertise in how to do the
interworking. As a result, the SIP working group, with the approval and
support of our area director (AD),  will be hosting a task force
targeted at generation of informational RFC on SIP to H.323
interworking. This task force will continue to use the existing list,
sip-h323@egroups.com. People working on these documents should feel free
to bring up questions and issues on the main SIP list
(sip@lists.research.bell-labs.com) in order to facilitate their work.

Should any issues arise during this work which might neccessitate
revisiting the need for standards track work on SIP-H.323 interworking,
the ADs have indicated that a new BoF could be scheduled to discuss
them.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 18:55:55 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27319
	for ; Mon, 27 Mar 2000 18:55:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 99C1F52D5; Mon, 27 Mar 2000 18:53:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 189DA52DC; Mon, 27 Mar 2000 18:53:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id EC74152D5
	for ; Mon, 27 Mar 2000 18:53:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 18:52:12 EST 2000
Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Mon Mar 27 18:52:11 EST 2000
Received: from vovida.com (pool0834.cvx20-bradley.dialup.earthlink.net [209.179.253.69])
	by repulse.cnchost.com
	id SAA03949; Mon, 27 Mar 2000 18:52:08 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38E010F4.D9AB0A2@vovida.com>
Date: Mon, 27 Mar 2000 17:55:00 -0800
From: Krishan Veer 
Organization: Vovida Networks
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Cc: Sunitha Kumar 
Subject: reg: SipURL
Content-Type: multipart/alternative;
 boundary="------------DBD11735D64EDA5DF08AEDB1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


--------------DBD11735D64EDA5DF08AEDB1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi everyone ,

Is this will be considered as Valid format of SIP URL


can USER=PHONE come inside the angular brackets "<>" ? or it should be
always outside the angular brackets seperated by ";" ??

Thanks : )

--
Krishan veer
Software Engineer
http://www.vovida.com



--------------DBD11735D64EDA5DF08AEDB1
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi everyone ,

Is this will be considered as Valid format of SIP URL

<sip:122233@gateway.com;user=phone>

can USER=PHONE come inside the angular brackets "<>" ? or it
should be always outside the angular brackets seperated by ";" ??

Thanks : )

-- 
Krishan veer
Software Engineer
http://www.vovida.com


 

--------------DBD11735D64EDA5DF08AEDB1--




From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 19:05:56 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27587
	for ; Mon, 27 Mar 2000 19:05:55 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 8316C52DD; Mon, 27 Mar 2000 19:03:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 09CD452DC; Mon, 27 Mar 2000 19:03:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 6BABB52DD
	for ; Mon, 27 Mar 2000 19:03:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 19:01:18 EST 2000
Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Mon Mar 27 19:01:17 EST 2000
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FS300EGUUQ4GA@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Tue, 28 Mar 2000 00:01:16 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FS300F01UQ38H@dgismtp01.wcomnet.com> for
 sip@lists.research.bell-labs.com; Tue, 28 Mar 2000 00:01:16 +0000 (GMT)
Received: from omzmta01.mcit.com ([166.37.214.7])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FS300E65UQ389@dgismtp01.wcomnet.com> for
 sip@lists.research.bell-labs.com; Tue, 28 Mar 2000 00:01:15 +0000 (GMT)
Received: from dwillispc8 ([166.44.58.172])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000328000114.NPIL19466@dwillispc8> for
 ; Tue, 28 Mar 2000 00:01:14 +0000
Date: Mon, 27 Mar 2000 18:00:29 -0600
From: Dean Willis 
Subject: Temporary Replacement for SIP WG Supplemental Page
To: IETF SIP 
Message-id: <001901bf9848$a0cfbf60$cdc0d0a9@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Well, the folks at Directlink can't seem to keep the DSL line working that
feeds the softarmor.com web site, so I have arranged a temporary (may make
it permanent) move to:

http://www.greycouncil.com/sipwg/

Please notify me of any difficulties.

--
Dean Willis
SIP WG cochair




From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 19:19:53 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27752
	for ; Mon, 27 Mar 2000 19:19:52 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 1505052DC; Mon, 27 Mar 2000 19:17:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 71B0C52DE; Mon, 27 Mar 2000 19:17:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 7841652DC
	for ; Mon, 27 Mar 2000 19:17:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 19:15:09 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon Mar 27 19:15:09 EST 2000
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA17233;
	Mon, 27 Mar 2000 19:16:15 -0500 (EST)
Message-ID: <38DFF92F.A17DE622@dynamicsoft.com>
Date: Mon, 27 Mar 2000 19:13:35 -0500
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Krishan Veer 
Cc: sip , Sunitha Kumar 
Subject: Re: reg: SipURL
References: <38E010F4.D9AB0A2@vovida.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Krishan Veer wrote:
> Is this will be considered as Valid format of SIP URL
> 

No, angle brackets are not allowed in SIP URLs. It is a valid form of
Contact, To or From headers, though.
 
> can USER=PHONE come inside the angular brackets "<>" ? 

It not only "can" but rather "should". It will be interpreted as a
header parameter if placed outside the brackets.

---
Igor Slepchin



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 19:24:02 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27785
	for ; Mon, 27 Mar 2000 19:24:01 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id BB59D52DF; Mon, 27 Mar 2000 19:21:26 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 13B4952DE; Mon, 27 Mar 2000 19:21:25 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 3EC7552E0
	for ; Mon, 27 Mar 2000 19:21:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 19:20:09 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon Mar 27 19:20:08 EST 2000
Received: from dynamicsoft.com (dhcp-192-171.ietf.connect.com.au [169.208.192.171])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA17237;
	Mon, 27 Mar 2000 19:21:15 -0500 (EST)
Message-ID: <38DFFC71.95215E2C@dynamicsoft.com>
Date: Mon, 27 Mar 2000 19:27:29 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Krishan Veer 
Cc: sip , Sunitha Kumar 
Subject: Re: reg: SipURL
References: <38E010F4.D9AB0A2@vovida.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Krishan Veer wrote:
> 
> Hi everyone ,
> 
> Is this will be considered as Valid format of SIP URL
> 
> 
> can USER=PHONE come inside the angular brackets "<>" ? or it should be
> always outside the angular brackets seperated by ";" ??

Back to the point I made on the list and during the meeting, this issue
has been discussed countless times on the list, during the meetings, and
is described in the spec itself. I strongly encourage people to check
these resources for answers to their questions.

The SIP URL does not define the brackets. The brackets are part of the
formatting of the To, From, and other SIP header fields. These brackets
must appear around the URL (including its parameters) if the URL in that
header has URL paramteres. user is a URL parameter, so if you use it in
a To, From, Contact or whatever, it appears inside the bracket.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 19:29:50 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27856
	for ; Mon, 27 Mar 2000 19:29:49 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 94FFC52E1; Mon, 27 Mar 2000 19:27:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 1130552DE; Mon, 27 Mar 2000 19:27:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 34CD652E1
	for ; Mon, 27 Mar 2000 19:27:08 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 19:27:02 EST 2000
Received: from dgesmtp01.wcom.com ([199.249.16.16]) by dusty; Mon Mar 27 19:27:01 EST 2000
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FS300E4HVWZNO@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Tue, 28 Mar 2000 00:26:59 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with ESMTP id <0FS300I01VWY1T@pmismtp02.wcomnet.com>;
 Tue, 28 Mar 2000 00:26:58 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0FS300EP0VWYHV@pmismtp02.wcomnet.com>; Tue,
 28 Mar 2000 00:26:58 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2571.0)
	id ; Tue, 28 Mar 2000 00:26:57 +0000
Content-return: allowed
Date: Tue, 28 Mar 2000 00:26:52 +0000
From: "Donovan, Steven R." 
Subject: RE: clarifications on 183 and "manyfolks" drafts
To: "'Jonathan Rosenberg'" ,
        Rohan Mahy 
Cc: William Marshall , sip@lists.research.bell-labs.com
Message-id: <75C79E507864D3118AFC00805FEAB7D834939C@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: text/plain; charset=ISO-8859-1
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


Jonathan Rosenberg wrote:
> 
> However, I disagree that the Session header only makes sense 
> for 183. I
> see no reason why. My view of the Session header is that it 
> informs the
> UA that there is some dependency on signaling behavior because of the
> session. The QoS and security Session: tokens in a request 
> indicate that
> the INVITE should not cause local alerting until the preconditions are
> met, and that a provisional response with SDP should be sent. The QoS 
> and security Session: in the provisional response indicates a similar
> thing - don't do anything with this message until the 
> preconditions are
> met. So, I would argue its OK to put a Session header in a 
> 180, in which
> case ringing (signaled by 180) doesn't occur until the 
> preconditions are
> met.
> 

It is also the case that not all scenarios require that the QoS and security
be established prior to alerting the called user.  We have outlined two
options in draft-sinnreich-interdomain-sip-qos-osp-01.txt.  The first is
call QoS assured, which is inline with the procedures outlined in the
manyfolks draft and would use the PRECONDITIONS-MET method.

The second is refered to as enabled, which decouples the SIP and QoS
signaling.  In this case, the SDP with called UA QoS information can be
carried in a 180 or 183 (depending on the type of called ua).  This scenario
does not require a PRECONDITIONS-MET method.

The confirm attribute in the proposed SDP extension drive the use of
PRECONDITIONS-MET.



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 20:02:02 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28267
	for ; Mon, 27 Mar 2000 20:02:00 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 401D252D4; Mon, 27 Mar 2000 19:59:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B5B0B52E5; Mon, 27 Mar 2000 19:59:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id AA90452D4
	for ; Mon, 27 Mar 2000 19:59:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 19:58:00 EST 2000
Received: from mail.huawei.com.cn ([202.96.135.132]) by dusty; Mon Mar 27 19:58:00 EST 2000
Received: from y13638 ([10.108.22.162]) by mail.huawei.com.cn
          (Netscape Mail Server v2.02) with SMTP id AAA27837
          for ;
          Tue, 28 Mar 2000 08:58:15 +0800
Message-ID: <000f01bf9850$7b2cc340$a2166c0a@y13638.huawei.com.cn>
Reply-To: "yinshaohua" 
From: "yinshaohua" 
To: 
Subject: About Multicast
Date: Tue, 28 Mar 2000 08:56:38 +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 4.72.3110.5
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi:
     I have a question regarding Multicast. The multicast is transmission of
the same data to a selected group of destinations.So the forking proxy is
the situation  of sending the SIP message to multicast address.
    In section 6.40 of RFC2543, there have "A proxy sending a request to a
multicast address must add 'maddr' pararmeter  to via header field ", But in
the section 16.5 of RFC2543, the example of forking proxy, the via header
have not add the "maddr" parameter.
    Is there wrong?

Shaohua Yin






From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 20:15:53 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28431
	for ; Mon, 27 Mar 2000 20:15:53 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id A647652E5; Mon, 27 Mar 2000 20:13:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 0CEFD52E6; Mon, 27 Mar 2000 20:13:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 814CE52E5
	for ; Mon, 27 Mar 2000 20:13:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 20:12:11 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon Mar 27 20:12:10 EST 2000
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA17313;
	Mon, 27 Mar 2000 20:13:12 -0500 (EST)
Message-ID: <38E00679.38B2320D@dynamicsoft.com>
Date: Mon, 27 Mar 2000 20:10:17 -0500
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: yinshaohua 
Cc: sip@lists.research.bell-labs.com
Subject: Re: About Multicast
References: <000f01bf9850$7b2cc340$a2166c0a@y13638.huawei.com.cn>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Forking a request to several unicast addresses is by no means equivalent
to multicasting it. 
The example in section 16.5 does not proxy the request to a multicast
addresses but to four unicast addresses.

---
Igor Slepchin


yinshaohua wrote:
> 
> Hi:
>      I have a question regarding Multicast. The multicast is transmission of
> the same data to a selected group of destinations.So the forking proxy is
> the situation  of sending the SIP message to multicast address.
>     In section 6.40 of RFC2543, there have "A proxy sending a request to a
> multicast address must add 'maddr' pararmeter  to via header field ", But in
> the section 16.5 of RFC2543, the example of forking proxy, the via header
> have not add the "maddr" parameter.
>     Is there wrong?
> 
> Shaohua Yin



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 20:22:01 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28523
	for ; Mon, 27 Mar 2000 20:22:00 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 5631E52E6; Mon, 27 Mar 2000 20:19:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D0AEA52E7; Mon, 27 Mar 2000 20:19:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 8A83352E6
	for ; Mon, 27 Mar 2000 20:19:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 20:17:28 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Mon Mar 27 20:17:27 EST 2000
Received: from dynamicsoft.com (dhcp-192-171.ietf.connect.com.au [169.208.192.171])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA17321;
	Mon, 27 Mar 2000 20:18:10 -0500 (EST)
Message-ID: <38E009C8.9A5DE800@dynamicsoft.com>
Date: Mon, 27 Mar 2000 20:24:24 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: yinshaohua 
Cc: sip@lists.research.bell-labs.com
Subject: Re: About Multicast
References: <000f01bf9850$7b2cc340$a2166c0a@y13638.huawei.com.cn>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



yinshaohua wrote:
> 
> Hi:
>      I have a question regarding Multicast. The multicast is transmission of
> the same data to a selected group of destinations.So the forking proxy is
> the situation  of sending the SIP message to multicast address.

No. Forking is not the same as multicast. Multicast refers to IP layer
multicast.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 20:41:57 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28958
	for ; Mon, 27 Mar 2000 20:41:56 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id A308152E2; Mon, 27 Mar 2000 20:39:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8528352E9; Mon, 27 Mar 2000 20:39:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id BD61F52E2
	for ; Mon, 27 Mar 2000 20:39:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 27 20:37:19 EST 2000
Received: from mail-dns1-nj.dialogic.com ([146.152.228.10]) by dusty; Mon Mar 27 20:37:18 EST 2000
Received: from mail4.dialogic.com ([146.152.6.40])
	by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id BAA26659;
	Tue, 28 Mar 2000 01:31:44 GMT
Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18])
 by mail4.dialogic.com (PMDF V5.2-31 #40816)
 with ESMTP id <0FS300CHBYTQYD@mail4.dialogic.com>; Mon,
 27 Mar 2000 20:29:51 -0500 (EST)
Received: by mailnj.dialogic.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 27 Mar 2000 20:29:53 -0500
Content-return: allowed
Date: Mon, 27 Mar 2000 20:30:11 -0500
From: "Kelley, Kalon" 
Subject: RE: SIP Request Glare.
To: "'Jonathan Rosenberg'" 
Cc: "'sip@lists.research.bell-labs.com'" 
Message-id: <3E006CE92E9AD3119F4E00105A0C3807C58122@exchange1nj.dialogic.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7BIT

Jonathan:

Thanks for turning your critical eye to this proposal.  Your points are
well-taken.  Further comments are interspersed below.


Jonathan Rosenberg wrote:
> 
> Regarding the glare issue, Kelly later writes:
> > We've introduced an alternate proposal in a recent I-D 
> (see, in particular,
> > section 7 of 
> http://www.ietf.org/internet-drafts/draft-mark-sip-dmcs-00.txt)
> > that attempts to address the problem.  Loosely, our proposal entails
> > comparing the URIs used in the To and From fields of the 
> INVITEs as the
> > basis for comparison.  The party whose URI is lesser is 
> designated the
> > victor when crossing INVITEs arise.
> 
> 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 w/ a 200 OK. Then, A gets the non-500 response 
> from B. Now A
> is really confused.
> 
> You could argue that B shouldn't even send that re-INVITE 
> until the ACK
> is received for the re-INVITE B got first. 

This is probably what I would argue.  However, it sounds like you're
uncomfortable with this.  What drawbacks are there to this requirement?

> However, there is still a
> race condition that makes it not work, although its 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 B 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.

Excellent catch.  Could we deal with this case by requiring the party that
is not the victor (here A) to CANCEL its re-INVITE (and wait until receiving
a response to that CANCEL) prior to accepting the victor's INVITE?  This
would keep the above situation from occurring, since by the time B receives
A's re-INVITE it will necessarily have received A's cancellation thereof.
In the event that a response to the CANCEL is not received within a
reasonable period of time, the client can resort to the basic back-off
Retry-After approach. (My initial instinct is to eliminate the separate
CANCEL step by having A somehow communicate the implied glare cancellation
by adding a header or other mechanism for passing the CSeq of its own
(losing) re-INVITE request in its 200 response to B's re-INVITE, but this
clearly suffers from the same lack of backwards compatibility you note in
conjunction with your fix below.)  

An unknown for me with such a solution is whether or not UASs are expected
to keep track of CANCEL requests for INVITEs they have not received, on the
off-chance that the CANCEL outpaces its INVITE.

> I think this can be fixed if each side includes, in a re-INVITE, the
> CSeq of the request last received from the other party (or -1 or
> something if it hasn't gotten one yet). This will allow each side to
> determine, when it receives a reinvite while reinviting, whether the
> reinvite it sent has been received and responded to by the other side.
> This requires an extension, and its not backwards compatible, which is
> kind of yucky. Below is an alternate solution.

I agree that this fix would work, but may be too "yucky" for the reasons
enumerated.

> 
> 
> 
> > 
> > Now regarding glare resolution: Is the proposed glare 
> resolution solution
> > acceptable in a telephony environment? The granularity of 
> Retry-After is in
> > seconds. So to have a reasonable chance of not colliding 
> again you must make
> > the random range large; yet it is unacceptable to have a 
> delay any more than
> > a second or two in most telephony applications. For 
> instance if the random
> > range of Retry-After is up to three seconds, then this only 
> allows three
> > random outcomes => leading to a roughly 33% chance of re-collision.
> > Additionally, even for this small value of Retry-After 
> there is roughly only
> > a 66% chance that a request will commence within 2 seconds 
> (which is still
> > unacceptable in many situations). Whether or not you have a 
> small or large
> > random range for Retry-After doesn't help because of the 
> lack of random
> > granularity.
> 
> Well, how about we add random granularity? We could simply 
> say that both
> sides should retry within a random time distributed between 0 and some
> number. This number has to be chosen large enough to reduce the
> probability of collision again, but small enough to make the re-invite
> resolve quickly. Glare happens again if both sides choose a number
> within 1/2 RTT of each other. Lets say 1/2 RTT = 50ms. If we want the
> re-glare case to happen with < 5% probability, choosing the number
> randomly between 0 and 1 second should work.

I think (modulo my math skills) it may be somewhat worse than this (see also
forthcoming response to Robert's mail.)  In particular, by my calculations
the random time selected must be between 0 and approximately 2.05s in order
to to limit the probability of recollision to 5% given the assumed 1/2 RTT
of 50 ms.

> This solution doesn't require an extension. Its not as fast as above,
> but its not as complex.
> 
> 
> -Jonathan R.
> 

Thanks again for your insights.

Kalon

Kalon Kelley
Intel Dialogic Division
mailto:Kalon.Kelley@dialogic.com
http://www.dialogic.com/



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 21:00:12 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29432
	for ; Mon, 27 Mar 2000 21:00:11 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 2BE9A52E9; Mon, 27 Mar 2000 20:57:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9651852EA; Mon, 27 Mar 2000 20:57:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 744B852E9
	for ; Mon, 27 Mar 2000 20:57:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 20:55:58 EST 2000
Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Mon Mar 27 20:55:57 EST 2000
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FS400E5C01879@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Tue, 28 Mar 2000 01:55:56 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with ESMTP id <0FS400B01017HE@pmismtp02.wcomnet.com>;
 Tue, 28 Mar 2000 01:55:56 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0FS400A3Y017UQ@pmismtp02.wcomnet.com>; Tue,
 28 Mar 2000 01:55:55 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2571.0)
	id ; Tue, 28 Mar 2000 01:55:55 +0000
Content-return: allowed
Date: Tue, 28 Mar 2000 01:55:50 +0000
From: "Donovan, Steven R." 
Subject: RE: Session timer comments
To: "'Anders Kristensen'" ,
        Jonathan Rosenberg 
Cc: Henning Schulzrinne ,
        SIP 
Message-id: <75C79E507864D3118AFC00805FEAB7D83493A2@ripexch001.mcit.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2571.0)
Content-type: text/plain; charset=ISO-8859-1
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Anders Kristensen wrote:

>  o The crashed UA may have had a route associated with the 
> leg. Allowing
> a re-INVITE to set up a leg in the crashed UAS as if it was 
> an original
> INVITE ignores the fact that subsequent requests should follow a route
> established prior to the crash.
> 

This is addressed by an addition to 2543bis:


  "Note that proxy servers have to add Record-Route headers to each
   request as long as they want to be "visited" by the next request
   for the call leg."

The only way for a proxy to insure that it will be a part of all requests is
to insert the Record-Route header into all requests, even those that have a
Route header.



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 21:13:56 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29595
	for ; Mon, 27 Mar 2000 21:13:55 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id E9A0152EA; Mon, 27 Mar 2000 21:11:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 6D3DC52EB; Mon, 27 Mar 2000 21:11:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 7B90952EA
	for ; Mon, 27 Mar 2000 21:11:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 21:10:59 EST 2000
Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Mon Mar 27 21:10:58 EST 2000
Received: from vovida.com (static-8-13.ietf.connect.com.au [169.208.8.13])
	by repulse.cnchost.com
	id VAA07403; Mon, 27 Mar 2000 21:10:53 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38E014DE.6704DAFA@vovida.com>
Date: Mon, 27 Mar 2000 18:11:42 -0800
From: Sunitha Kumar 
Organization: Vovida Networks
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: zh,zh-CN,en
MIME-Version: 1.0
To: Krishan Veer 
Cc: sip 
Subject: Re: reg: SipURL
References: <38E010F4.D9AB0A2@vovida.com>
Content-Type: multipart/alternative;
 boundary="------------88F766CBDCF6D1630F143CD1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


--------------88F766CBDCF6D1630F143CD1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Krishan:

If you look at the From or To fields and the  addr-spec param , this is
nothing but the SIP url, so it is From:  or
    From: name-addr; where name-addr is : display_name
    and addr-spec = sipUrl.

So, what ever is contained in the SIP url goes into < >, including
user=phone.

Hope that helps.

sunitha

Krishan Veer wrote:

> Hi everyone ,
>
> Is this will be considered as Valid format of SIP URL
> 
>
> can USER=PHONE come inside the angular brackets "<>" ? or it should be
> always outside the angular brackets seperated by ";" ??
>
> Thanks : )
>
> --
> Krishan veer
> Software Engineer
> http://www.vovida.com
>
>

--------------88F766CBDCF6D1630F143CD1
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Krishan:

If you look at the From or To fields and the  addr-spec param ,
this is nothing but the SIP url, so it is From: <addr-spec> or

    From: name-addr; where name-addr is : display_name<addr-spec>

    and addr-spec = sipUrl.

So, what ever is contained in the SIP url goes into < >, including
user=phone.

Hope that helps.

sunitha

Krishan Veer wrote:

Hi everyone ,

Is this will be considered as Valid format of SIP URL

<sip:122233@gateway.com;user=phone>

can USER=PHONE come inside the angular brackets "<>" ? or it should
be always outside the angular brackets seperated by ";" ??

Thanks : )

-- 
Krishan veer
Software Engineer
http://www.vovida.com

 



--------------88F766CBDCF6D1630F143CD1--




From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 21:59:56 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01039
	for ; Mon, 27 Mar 2000 21:59:56 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 54E4752E7; Mon, 27 Mar 2000 21:57:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id CE01652EC; Mon, 27 Mar 2000 21:57:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 21D1F52E7
	for ; Mon, 27 Mar 2000 21:57:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 21:56:01 EST 2000
Received: from longmail.lboard.com ([204.17.219.203]) by dusty; Mon Mar 27 21:56:00 EST 2000
Received: by mail with Internet Mail Service (5.5.2650.21)
	id ; Mon, 27 Mar 2000 19:02:20 -0800
Message-ID: 
From: Marcelo San Martin 
To: sip@lists.research.bell-labs.com
Subject: LALR SIP Gramar
Date: Mon, 27 Mar 2000 19:02:19 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Hi,

Could you please tell me if there is a LALR Sip gramar (yacc/bison)
available? so far I have seen only a BNF gramar.

Thanks very much,

Marcelo San Martin



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 22:27:54 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01602
	for ; Mon, 27 Mar 2000 22:27:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 7EB4052EC; Mon, 27 Mar 2000 22:25:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 00FDD52ED; Mon, 27 Mar 2000 22:25:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id A584152EC
	for ; Mon, 27 Mar 2000 22:25:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 22:23:56 EST 2000
Received: from mail.iagu.net ([203.32.153.69]) by dusty; Mon Mar 27 22:23:55 EST 2000
Received: from dhcp-32-247.ietf.connect.com.au [169.208.32.247]
  by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id MAA02542
  return ;
  Tue, 28 Mar 2000 12:53:48 +0930 (CST)
Message-ID: <38E08F16.C3631601@italtel.it>
Date: Tue, 28 Mar 2000 12:53:11 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: Billing SIP proxy
Content-Type: multipart/alternative;
 boundary="------------7BCB457D8CEC7219CCCAC753"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


--------------7BCB457D8CEC7219CCCAC753
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear All,

during these days in Adelaide, I have already had the chance to discuss
with some well known SIP experts about this topic, nevertheless I would
like to pose the same question to the list: maybe someone has some other
idea.

Let' s assme that the scenaro is:

   * there are a number of "standard" SIP terminals, whose software is
     not modifiable by the user (nor any other application can be
     installed)
   * such SIP softare forces SIP to work in proxy mode
   * the proxy actually bills the calls

Now let' s introduce a "hacked" terminal, and lets' s say that the
software on such terminal is completely free, in the sense that whatever
is needed we can modify it and install it.

The question is: is it posible to define, to any extent, a mechanism
capable of preventing the "hacked" terminal to bypass the proxy and call
the "standard" endpoints witout being billed ?

Please CC replies to gricagni@tin.it (it is easier for me to read email
from such mailbox here in Adelaide)


Please let me know
Best Regards
Giuseppe


--------------7BCB457D8CEC7219CCCAC753
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Dear All,

during these days in Adelaide, I have already had the chance to discuss
with some well known SIP experts about this topic, nevertheless I would
like to pose the same question to the list: maybe someone has some other
idea.

Let' s assme that the scenaro is:

    

  • 
there are a number of "standard" SIP terminals, whose software is not modifiable
by the user (nor any other application can be installed)
    • 


  • 
such SIP softare forces SIP to work in proxy mode
    • 


  • 
the proxy actually bills the calls
    • 


Now let' s introduce a "hacked" terminal, and lets' s say that the software
on such terminal is completely free, in the sense that whatever is needed
we can modify it and install it.

The question is: is it posible to define, to any extent, a mechanism
capable of preventing the "hacked" terminal to bypass the proxy and call
the "standard" endpoints witout being billed ?

Please CC replies to gricagni@tin.it (it is easier for me to read email
from such mailbox here in Adelaide)

 

Please let me know

Best Regards

Giuseppe

 

--------------7BCB457D8CEC7219CCCAC753--





From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 22:43:51 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02745
	for ; Mon, 27 Mar 2000 22:43:51 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 7AA4D52EB; Mon, 27 Mar 2000 22:41:20 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id F2BE652EE; Mon, 27 Mar 2000 22:41:19 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 5264B52EB
	for ; Mon, 27 Mar 2000 22:41:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 27 22:40:11 EST 2000
Received: from newdev.harvard.edu ([140.247.60.212]) by dusty; Mon Mar 27 22:40:10 EST 2000
Received: (from sob@localhost)
	by newdev.harvard.edu (8.9.3/8.9.3) id WAA00664;
	Mon, 27 Mar 2000 22:40:03 -0500 (EST)
Date: Mon, 27 Mar 2000 22:40:03 -0500 (EST)
From: Scott Bradner 
Message-Id: <200003280340.WAA00664@newdev.harvard.edu>
To: giuseppe.ricagni@italtel.it, sip@lists.research.bell-labs.com
Subject: Re: Billing SIP proxy
Cc: gricagni@tin.it
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

> The question is: is it posible to define, to any extent, a mechanism
> capable of preventing the "hacked" terminal to bypass the proxy and call
> the "standard" endpoints witout being billed ?

if they are not making any special use of the network (like QoS
reservations or fancy proxy services ) why should they be billed
in a way that is different than any other best-effort use of the
network?

Scott



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 23:22:07 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03342
	for ; Mon, 27 Mar 2000 23:22:07 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 421A852E4; Mon, 27 Mar 2000 23:19:25 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B2DB152E3; Mon, 27 Mar 2000 23:19:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id BD6D452EE
	for ; Mon, 27 Mar 2000 23:19:08 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 23:18:07 EST 2000
Received: from avocet.prod.itd.earthlink.net ([207.217.121.50]) by dusty; Mon Mar 27 23:18:06 EST 2000
Received: from bbk.pingtel.com (dialup-209.245.139.216.SanJose1.Level3.net [209.245.139.216])
	by avocet.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id UAA01315;
	Mon, 27 Mar 2000 20:17:52 -0800 (PST)
Message-Id: <4.3.2.20000327230352.00aed8f0@mail.pingtel.com>
X-Sender: jabatson@mail.earthlink.net
X-Mailer: QUALCOMM Windows Eudora Version 4.3
Date: Mon, 27 Mar 2000 23:24:44 -0500
To: sip@lists.research.bell-labs.com, gricagni@tin.it
From: Jay Batson 
Subject: Re: Billing SIP proxy
In-Reply-To: <38E08F16.C3631601@italtel.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

IMHO, there will always be UAs that do not want to be forced against their 
desire to use a particular proxy.  If I'm a died-in-the-wool Net-Head, I 
may very well be happy with:

- making a call from my Pingtel phone (at sip:jbatson@pingtel.com) to 
Henning's SIP address ( at sip:hgs@cs.columbia.edu);

- having my Pingtel phone sends the INVITE directly to Henning's proxy 
(without my service provider being involved);

- having everything going across the public Internet, getting "best 
efforts" delivery of everything;

- which doesn't require any service provider anywhere to know about or care 
about the call.

Which, of course, is exactly what SIP does now, thank you.  So I'll be very 
happy not to see us "break" the swell protocol we have... ;-)

I'm sympathetic to the problems of a service provider who wants to bill for 
connections.  But this question feels to me like a similar question I heard 
a few years ago when X.25 messaging vendors were asking the same question 
about SMTP/POP....  SMTP/POP kinda torpedoed existing business models (of 
charging for email transport).  SIP may pose similar challenges for 
"pay-for-connection" business models.  Fortunately, it gives service 
providers a nifty mechanism to create new services to replace that lost 
revenue....

Cheers
-jb


>Now let' s introduce a "hacked" terminal, and lets' s say that the 
>software on such terminal is completely free, in the sense that whatever 
>is needed we can modify it and install it.
>
>The question is: is it posible to define, to any extent, a mechanism 
>capable of preventing the "hacked" terminal to bypass the proxy and call 
>the "standard" endpoints witout being billed ?




From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 23:26:14 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03391
	for ; Mon, 27 Mar 2000 23:26:13 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 2F07252E3; Mon, 27 Mar 2000 23:21:50 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id F2FF652EE; Mon, 27 Mar 2000 23:21:48 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id C6E7252E3
	for ; Mon, 27 Mar 2000 23:21:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 27 23:19:28 EST 2000
Received: from hubbub.cisco.com ([171.69.11.2]) by dusty; Mon Mar 27 23:19:28 EST 2000
Received: from ORANLT (ssh.cisco.com [171.69.10.34]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id UAA27597; Mon, 27 Mar 2000 20:19:21 -0800 (PST)
From: "David Oran" 
To: "Giuseppe Ricagni" ,
        
Cc: 
Subject: RE: Billing SIP proxy
Date: Mon, 27 Mar 2000 23:19:21 -0500
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: <38E08F16.C3631601@italtel.it>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

>The question is: is it posible to define, to any extent, a mechanism
capable >of preventing the "hacked" terminal to bypass the proxy and call
the >"standard" endpoints witout being billed ?

There's no way to prevent one "hacked terminal" from talking to another
"hacked terminal" directly, bypassing any proxy.

You can, at some pain, protect against is having a "standard terminal"
answer a call from a "hacked terminal". The way you do this is when a SIP
message comes into the UAC, ou look at the last VIA on the via list. You
then get the IP address of that machine (either because it was on the VIA
istelf or you called DNS to get its address) and compare that with the
source address of the SIP message. If they don't match, you know somebody is
trying to spoof you.

If they DO match, then if the SIP UAC knows the list of SIP proxies which it
trusts to deliver calls (and bill for them), the UAC either accepts or
rejects the request appropriately.


> Please CC replies to gricagni@tin.it (it is easier for me to read email
from > such mailbox here in Adelaide)

>Please let me know
>Best Regards
>Giuseppe





From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 23:43:53 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04085
	for ; Mon, 27 Mar 2000 23:43:53 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id A3E5A52ED; Mon, 27 Mar 2000 23:41:21 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 1F7BF52EF; Mon, 27 Mar 2000 23:41:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 63DC052ED
	for ; Mon, 27 Mar 2000 23:41:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Mar 27 23:40:52 EST 2000
Received: from exchangesvr.nuera.com ([204.216.240.124]) by dusty; Mon Mar 27 23:40:51 EST 2000
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 27 Mar 2000 20:41:00 -0800
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: sip@lists.research.bell-labs.com, gricagni@tin.it
Subject: RE: Billing SIP proxy
Date: Mon, 27 Mar 2000 20:40:59 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


I agree with Jay that this is not a SIP protocol issue but a network issue.
If you want to prevent hacked terminals located on your own network from
accessing the Internet then simply use a SIP Proxy-Firewall solution. Now
UAC's cannot access the outside Internet unless they authenticate themselves
to the proxy-firewall. Likewise, the proxy-firewall does not allow external
clients to talk to internal terminals without authentication. The
Authentication procedures are expressly designed to ensure that only valid
users have access to the proxy, however, you can only ensure that hacked
terminals do not _bypass_ the proxy by coupling the SIP proxy with a
firewall.

Cheers,

Robert.



From owner-sip-outgoing@lists.research.bell-labs.com  Mon Mar 27 23:58:00 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04278
	for ; Mon, 27 Mar 2000 23:58:00 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 69D7A52F0; Mon, 27 Mar 2000 23:55:28 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id DC79B52EF; Mon, 27 Mar 2000 23:55:27 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id BAA0A52F2
	for ; Mon, 27 Mar 2000 23:55:09 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Mar 27 23:53:47 EST 2000
Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Mon Mar 27 23:53:46 EST 2000
Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id XAA26298;
	Mon, 27 Mar 2000 23:53:46 -0500 (EST)
Received: (from lennox@localhost)
	by conrail.cs.columbia.edu (8.9.3/8.9.1) id XAA27441;
	Mon, 27 Mar 2000 23:53:46 -0500 (EST)
	(envelope-from lennox)
Date: Mon, 27 Mar 2000 23:53:46 -0500 (EST)
Message-Id: <200003280453.XAA27441@conrail.cs.columbia.edu>
From: Jonathan Lennox 
To: Giuseppe Ricagni 
Cc: sip@lists.research.bell-labs.com
Subject: Re: Billing SIP proxy
In-Reply-To: <38E08F16.C3631601@italtel.it>
References: <38E08F16.C3631601@italtel.it>
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

On Tue, March 28 2000, "Giuseppe Ricagni" wrote to "sip@lists.research.bell-labs.com" saying:

> during these days in Adelaide, I have already had the chance to discuss
> with some well known SIP experts about this topic, nevertheless I would
> like to pose the same question to the list: maybe someone has some other
> idea.
> 
> Let' s assme that the scenaro is:
> 
>    * there are a number of "standard" SIP terminals, whose software is
>      not modifiable by the user (nor any other application can be
>      installed)
>    * such SIP softare forces SIP to work in proxy mode
>    * the proxy actually bills the calls
> 
> Now let' s introduce a "hacked" terminal, and lets' s say that the
> software on such terminal is completely free, in the sense that whatever
> is needed we can modify it and install it.
> 
> The question is: is it posible to define, to any extent, a mechanism
> capable of preventing the "hacked" terminal to bypass the proxy and call
> the "standard" endpoints witout being billed ?
> 
> Please CC replies to gricagni@tin.it (it is easier for me to read email
> from such mailbox here in Adelaide)

Put the terminals behind a firewall which doesn't allow random UDP packets
through.  Have the SIP proxy tell the firewall to open up the ports for each
call's RTP streams after it processes the corresponding INVITE.  Close them
when you see the BYE or when a session-timer expires (you'll need session
timers for this to work).

This, of course, forces you to provide application-level gateways for every
UDP-using protocol your customers want to use.  It also leads to the
question of why your customers won't just decamp to a provider who gives
them proper end-to-end IP service, and only bills for true value-added
features.

-- 
Jonathan Lennox
lennox@cs.columbia.edu



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 00:28:39 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04543
	for ; Tue, 28 Mar 2000 00:28:39 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id EE56E52EF; Tue, 28 Mar 2000 00:23:52 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 4106752F1; Tue, 28 Mar 2000 00:23:51 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 33F1952EF
	for ; Tue, 28 Mar 2000 00:23:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 28 00:21:23 EST 2000
Received: from ns.fmmo.ca ([207.253.160.156]) by dusty; Tue Mar 28 00:21:22 EST 2000
Received: from localhost (fm-listproc@localhost)
	by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id AAA31462;
	Tue, 28 Mar 2000 00:22:48 -0500
Date: Tue, 28 Mar 2000 00:22:47 -0500 (EST)
From: Francois Menard List Account 
To: Jonathan Lennox 
Cc: Giuseppe Ricagni , sip@lists.research.bell-labs.com
Subject: Re: Billing SIP proxy
In-Reply-To: <200003280453.XAA27441@conrail.cs.columbia.edu>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

> This, of course, forces you to provide application-level gateways for every
> UDP-using protocol your customers want to use.  It also leads to the
> question of why your customers won't just decamp to a provider who gives
> them proper end-to-end IP service, and only bills for true value-added
> features.

There aren't too many options. Either you own the network, in which case
you firewall your users (i.e. a la PSTN STPs and CLASS5 firewalls, ahem,
switches) or you own the terminals (rent hardwired IP phones hooked to
your own proxy servers).  If an end-user hacks your phones, then you need
to own the network do do something.  I contend that most problems will
disappear as the speed of the access ramp increases significantly as to
make the issue of managing QoS a worthless exercise.  Then the only way to
assert vertical control over an ocean of bandwidth is to build the better
ships and the better docks. 

-=Francois=-
fmenard@fmmo.ca






From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 00:44:36 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04793
	for ; Tue, 28 Mar 2000 00:44:36 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 6391852EE; Tue, 28 Mar 2000 00:40:04 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 9967C52F2; Tue, 28 Mar 2000 00:40:03 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 97CAE52EE
	for ; Tue, 28 Mar 2000 00:39:08 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 00:38:30 EST 2000
Received: from mail-dns1-nj.dialogic.com ([146.152.228.10]) by dusty; Tue Mar 28 00:38:28 EST 2000
Received: from mail4.dialogic.com ([146.152.6.40])
	by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id FAA29041;
	Tue, 28 Mar 2000 05:40:06 GMT
Received: from exchange4nj.dialogic.com
 (exchange4nj.dialogic.com [146.152.3.19])
 by mail4.dialogic.com (PMDF V5.2-31 #40816)
 with ESMTP id <0FS400F2CABOAP@mail4.dialogic.com>; Tue,
 28 Mar 2000 00:38:12 -0500 (EST)
Received: by exchange4nj.dialogic.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 28 Mar 2000 00:38:25 -0500
Content-return: allowed
Date: Tue, 28 Mar 2000 00:38:29 -0500
From: "Kelley, Kalon" 
Subject: RE: SIP Request Glare.
To: "'Fairlie-Cuninghame, Robert'" ,
        "'Jonathan Rosenberg'" 
Cc: "'sip@lists.research.bell-labs.com'" 
Message-id: <3E006CE92E9AD3119F4E00105A0C3807C58123@exchange1nj.dialogic.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA04793

Robert Fairlie-Cuninghame wrote:


> 
> Maybe my math's is wrong but for RTT=100ms with a random 
> retransmit range of
> 0-1 second isn't the chance of recollision equal to (0.95 * 
> 100ms) + (0.05 *
> (0.75 * 100ms)) = 8.75%. 
> 
> Is this solution acceptable for connections where the RTT is larger?
> Consider a ½ RTT of 150 ms which is a quite noticeable but  
> tolerable delay
> for voice media, however, the actual SIP RTT may be quite 
> larger than the
> media path. Now, if we chose 1 second for the random 
> retransmit range I
> believe this gives a chance of recollision of around 28%.  
> 500ms RTT -> ~44%
> (if my maths is correct). Loaded proxies and the like could 
> conceivably
> create an even longer SIP RTT, no ? 


Robert:

I think your calculations are in the same general ballpark as mine (although
I put the chance of recollision assuming 100ms RTT with a random retransmit
range of 0-1s at 9.75%.)  Coming at it another way, it may be helpful to
calculate the retransmit range required given assumptions about both
expected RTTs and what we believe to be a reasonable level of recollision.

In the following equations:

R = the retransmit range
L = the assumption as to 1/2 RTT
P = the total probability of recollision


Take party A's randomly selected retry-after value.

1.  When it is greater than or equal to 1/2 RTT and less than or equal to
the retransmit range less 1/2 RTT (the probability of this occurrence can be
expressed as (R-2L)/R ), there will be a recollision if party B's
retry-after value is anywhere in the single RTT range beginning with party
A's value less 1/2 RTT and ending with party A's value plus 1/2 RTT (the
probability of this occurrence can be expressed as 2L/R).  Hence, the
probability for recollision in this circumstance can be expressed as:

((R-2L)/R) * (2L/R)

2.  When A's retry-after value is less than L (probability L/R), there will
be a recollision if B's retry-after value is less than A's value plus L.
The combined probability of this event can be integrated over the range of
A's possible retry-after values in this range, yielding a total probability
for this circumstance of ((3/2)*(L^2))/(R^2).

3.  When A's retry-after value is greater than R-L (probability L/R), there
will be a recollision if B's retry-after value is greater than A's value
less L.  As in (2), the total probability for this circumstance is
((3/2)*(L^2))/(R^2).

Therefore, adding these different probabilities yields:

P = (((R-2L)/R) * (2L/R))) + ((3*(L^2))/(R^2))

or (P*(R^2)) - ((2L)*R) + (L^2) = 0


By my calculations, solving for R given L=.05s, and P=.05 yields R of ~1.97s
(I erroneously reported this to be 2.05s in an earlier message.)

Solving for R given L=.15s and P=.05 yields R of ~5.92s.

Obviously it will be important to decide what assumptions are reasonable for
L and P in order to determine whether the random backoff approach is viable.

Please let me know of errors in this equation or computation.


Regards,

Kalon Kelley
Intel Dialogic Division



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 05:16:10 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19167
	for ; Tue, 28 Mar 2000 05:16:09 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id D30C652F3; Tue, 28 Mar 2000 05:13:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 4E84C52F5; Tue, 28 Mar 2000 05:13:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 26C3D52F3
	for ; Tue, 28 Mar 2000 05:13:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 05:11:52 EST 2000
Received: from mail.iagu.net ([203.32.153.69]) by dusty; Tue Mar 28 05:11:50 EST 2000
Received: from dhcp-32-247.ietf.connect.com.au [169.208.32.247]
  by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id TAA03917
  for  return ;
  Tue, 28 Mar 2000 19:41:46 +0930 (CST)
Message-ID: <38E0EEEC.15649047@italtel.it>
Date: Tue, 28 Mar 2000 19:42:04 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Sip list 
Subject: Re: Billing SIP proxy
Content-Type: multipart/alternative;
 boundary="------------B393182FC710A5D9A9DB6B54"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


--------------B393182FC710A5D9A9DB6B54
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

David Oran wrote:

> >The question is: is it posible to define, to any extent, a mechanism
> capable >of preventing the "hacked" terminal to bypass the proxy and
> call
> the >"standard" endpoints witout being billed ?
>
> There's no way to prevent one "hacked terminal" from talking to
> another
> "hacked terminal" directly, bypassing any proxy.
>

Fine, this is just impossible to prevent.

Then, I had in mind some via-header based solutions but, eventually, I
managed to hack all of them. It looks like the one you propose requires
some more thinking.....

> You can, at some pain, protect against is having a "standard terminal"
>
> answer a call from a "hacked terminal". The way you do this is when a
> SIP
> message comes into the UAC, ou look at the last VIA on the via list.
> You
> then get the IP address of that machine (either because it was on the
> VIA
> istelf or you called DNS to get its address) and compare that with the
>
> source address of the SIP message.

I assume you mean "Source address of the IP packet containing the SIP
message", right ?

> If they don't match, you know somebody is
> trying to spoof you.

mmm, let me think....

got it !?!?!?

   * 1) what if there' s a NAT in between ?

   * 2) vhat if the proxy "must be in the list", but not necessarily as
     the last one ? (E.g. because the proxy that bills you is that of
     your "home network", and you have moved somewhere else)

   * 2) on the other hand, if you  want the billing proxy always to be
     the last one (apart from all the clearinghouse-related issues Henry
     was mentioning today), it must be communicated upon registration. I
     must think about this, but I have the feeling that a possibility
     might be that  I can fool the "standard" terminal to re-register
     with me (the hacked terminal) making him believe I am "the proxy".
     I would obviously be adding my address to the VIA header when
     inviting him.

   * 3) I will think a little bit more about it

   * 4) Anyway, do yo agree with me that the complexity of the "crack"
     required to "patch" such features on the "standard" terminal (going
     back therefore to the first case you mentioned) is definetly much
     smaller than that of installing a complete protocol from scratch on
     a device that was not designed to run it ?

Thank you very much and
Best Regards
Giuseppe

>
> If they DO match, then if the SIP UAC knows the list of SIP proxies
> which it
> trusts to deliver calls (and bill for them), the UAC either accepts or
>
> rejects the request appropriately.
>
> > Please CC replies to gricagni@tin.it (it is easier for me to read
> email
> from > such mailbox here in Adelaide)
>
> >Please let me know
> >Best Regards
> >Giuseppe

--------------B393182FC710A5D9A9DB6B54
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



David,

David Oran wrote:

>The question is: is it posible to define, to any
extent, a mechanism

capable >of preventing the "hacked" terminal to bypass the proxy and
call

the >"standard" endpoints witout being billed ?

There's no way to prevent one "hacked terminal" from talking to another

"hacked terminal" directly, bypassing any proxy.

 

Fine, this is just impossible to prevent.

Then, I had in mind some via-header based solutions but, eventually,
I managed to hack all of them. It looks like the one you propose requires
some more thinking.....

You can, at some pain, protect against is having
a "standard terminal"

answer a call from a "hacked terminal". The way you do this is when
a SIP

message comes into the UAC, ou look at the last VIA on the via list.
You

then get the IP address of that machine (either because it was on the
VIA

istelf or you called DNS to get its address) and compare that with
the

source address of the SIP message.

I assume you mean "Source address of the IP packet containing the SIP message",
right ?

If they don't match, you know somebody is

trying to spoof you.

mmm, let me think....

got it !?!?!?

    

  • 
1) what if there' s a NAT in between ?
    • 




    

  • 
2) vhat if the proxy "must be in the list", but not necessarily as 
the last one ? (E.g. because the proxy that bills you is that of your "home
network", and you have moved somewhere else)
    • 




    

  • 
2) on the other hand, if you  want the billing proxy always to be
the last one (apart from all the clearinghouse-related issues Henry was
mentioning today), it must be communicated upon registration. I must think
about this, but I have the feeling that a possibility might be that 
I can fool the "standard" terminal to re-register with me (the hacked terminal)
making him believe I am "the proxy". I would obviously be adding my address
to the VIA header when inviting him.
    • 




    

  • 
3) I will think a little bit more about it
    • 




    

  • 
4) Anyway, do yo agree with me that the complexity of the "crack" required
to "patch" such features on the "standard" terminal (going back therefore
to the first case you mentioned) is definetly much smaller than that of
installing a complete protocol from scratch on a device that was not designed
to run it ?
    • 





Thank you very much and

Best Regards

Giuseppe

 

If they DO match, then if the SIP UAC knows the list of SIP proxies
which it

trusts to deliver calls (and bill for them), the UAC either accepts
or

rejects the request appropriately.

> Please CC replies to gricagni@tin.it (it is easier for me to read
email

from > such mailbox here in Adelaide)

>Please let me know

>Best Regards

>Giuseppe



--------------B393182FC710A5D9A9DB6B54--




From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 05:25:02 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19228
	for ; Tue, 28 Mar 2000 05:25:02 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 1275852F5; Tue, 28 Mar 2000 05:21:41 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 7730952F6; Tue, 28 Mar 2000 05:21:40 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id DEC5052F5
	for ; Tue, 28 Mar 2000 05:21:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 28 05:20:42 EST 2000
Received: from mail.iagu.net ([203.32.153.69]) by dusty; Tue Mar 28 05:20:37 EST 2000
Received: from dhcp-32-247.ietf.connect.com.au [169.208.32.247]
  by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id TAA03895
  for  return ;
  Tue, 28 Mar 2000 19:50:28 +0930 (CST)
Message-ID: <38E0F08C.DCAD4369@italtel.it>
Date: Tue, 28 Mar 2000 19:49:00 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Sip list 
Subject: Re: Billing SIP proxy
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Fairlie-Cuninghame, Robert" wrote:

> I agree with Jay that this is not a SIP protocol issue but a network issue.
> If you want to prevent hacked terminals located on your own network from
> accessing the Internet then simply use a SIP Proxy-Firewall solution.

 what if both terminals are on my same network ? Where do I put the
firewall ?

Cheers
Giuseppe

> Now
> UAC's cannot access the outside Internet unless they authenticate themselves
> to the proxy-firewall. Likewise, the proxy-firewall does not allow external
> clients to talk to internal terminals without authentication. The
> Authentication procedures are expressly designed to ensure that only valid
> users have access to the proxy, however, you can only ensure that hacked
> terminals do not _bypass_ the proxy by coupling the SIP proxy with a
> firewall.
>
> Cheers,
>
> Robert.




From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 05:28:15 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19239
	for ; Tue, 28 Mar 2000 05:28:15 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 5A39952F8; Tue, 28 Mar 2000 05:21:53 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 75A4B52F7; Tue, 28 Mar 2000 05:21:51 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 0A19252F9
	for ; Tue, 28 Mar 2000 05:21:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 05:20:35 EST 2000
Received: from mail.iagu.net ([203.32.153.69]) by dusty; Tue Mar 28 05:20:34 EST 2000
Received: from dhcp-32-247.ietf.connect.com.au [169.208.32.247]
  by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id TAA28024
  for  return ;
  Tue, 28 Mar 2000 19:50:26 +0930 (CST)
Message-ID: <38E0F040.A64D5FD3@italtel.it>
Date: Tue, 28 Mar 2000 19:47:44 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Sip list 
Subject: Re: Billing SIP proxy
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Scott,

Scott Bradner wrote:

> > The question is: is it posible to define, to any extent, a mechanism
> > capable of preventing the "hacked" terminal to bypass the proxy and call
> > the "standard" endpoints witout being billed ?
>
> if they are not making any special use of the network (like QoS
> reservations or fancy proxy services ) why should they be billed
> in a way that is different than any other best-effort use of the
> network?
>

Some telephony applications are currently heavily billed, at a rate much
higher than the corresponding rate for pure best effort Internet access.

In some domains, network operators hold a kind of oligopoly, thanks to
government policies, that grant licencies only to a very restricted
number of
operators.
Please don' t quote me on this, but I would say that there is no real
competition between them, at least not harsh competition.

At the moment, they are deciding wheter to continue with circuit
switched
networks or whethether to adopt IP-based networks.

It is very likely that they make such a step *only* if they don' t see
their
revenues reduced (hopefully, they would like to increase them !)

A model where best effort calls are free and QOS calls are billed will
pobably
apply in the future, but not in the short run, at least IMHO.

Giuseppe





From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 06:26:09 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19609
	for ; Tue, 28 Mar 2000 06:26:09 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id EDE8852F4; Tue, 28 Mar 2000 06:23:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5DB8D52F7; Tue, 28 Mar 2000 06:23:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 629D952F4
	for ; Tue, 28 Mar 2000 06:23:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 28 06:21:32 EST 2000
Received: from mail.iagu.net ([203.32.153.69]) by dusty; Tue Mar 28 06:21:30 EST 2000
Received: from dhcp-32-247.ietf.connect.com.au [169.208.32.247]
  by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id UAA04013
  return ;
  Tue, 28 Mar 2000 20:50:43 +0930 (CST)
Message-ID: <38E0FF15.53697C00@italtel.it>
Date: Tue, 28 Mar 2000 20:51:02 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Lennox 
Cc: Giuseppe Ricagni , sip@lists.research.bell-labs.com
Subject: Re: Billing SIP proxy
References: <38E08F16.C3631601@italtel.it> <200003280453.XAA27441@conrail.cs.columbia.edu>
Content-Type: multipart/alternative;
 boundary="------------D90E23E9BA5A7CCEC8323071"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


--------------D90E23E9BA5A7CCEC8323071
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jonathan,

let me say that I' m a bit tired  but, I'll try anyway... (forgive me if I say anything terribly
wrong)

Let' s even assume I can put each terminal behind a firewall, as you described (which is
something that, in our architecture, might even be feasible):

+---+               +------------+
| te1 |--------->|FW+Proxy1|------->+
+--+        +------------+            |
                                                           |
                                                           |
+---+               +------------+            |
| te2 |<---------|FW+Proxy2 |<-------+
+--+        +------------+


Now, by assumption, TE1 is hacked: I can do whatever I want with it.

Well this network must be connected to the Internet: let's assume there is a firewall3 towards
the Net.
It is configured to let HTTP pass through as well as incoming INVITE and ACK messages (this is
necessary to interoperate with the other PNOs).

Now let me start my own business "freecalls Inc." (or, at least, "cut price calls inc...."), also
selling  terminals that

   *  incapsulate SIP in HTTP ===> [FW+Proxy1] doesn't detect the INVITE nor the ACK
   *  send the packetized voice via TCP to my magic server in the Net

+---+               +------------+
| te1 |--------->|FW+Proxy1|--------+
+--+        +------------+            |
                                                           |+-----+
+----------------------------+
                                                           | FW3 |--------->|Server (in the
public Internet)+
                             +-----+       +----------------------------+
                                                          |
                                                           |
+---+               +------------+            |
| te2 |<---------|FW+Proxy2 |--------+
+--+        +------------+


and that' s  it: the server performs all the required translatons and sends all the SIP
signalling and an RTP stream to TE2.

Well, I have to admit it is not very optimized, but I designed it in half an hour....
.....I' sure our crowds of estimed hackers will be able to devise some much more efficient
solutions....

Ciao
Giuseppe

P.S.
1st optimization: you said that "This, of course, forces you to provide application-level
gateways for every UDP-using protocol your customers want to use."
Instead of tunneling Firewall1 with HTTP+TCP, I could try with one of such UDP-based protocols...
(much better !)









Jonathan Lennox wrote:

> On Tue, March 28 2000, "Giuseppe Ricagni" wrote to "sip@lists.research.bell-labs.com" saying:
>
> > during these days in Adelaide, I have already had the chance to discuss
> > with some well known SIP experts about this topic, nevertheless I would
> > like to pose the same question to the list: maybe someone has some other
> > idea.
> >
> > Let' s assme that the scenaro is:
> >
> >    * there are a number of "standard" SIP terminals, whose software is
> >      not modifiable by the user (nor any other application can be
> >      installed)
> >    * such SIP softare forces SIP to work in proxy mode
> >    * the proxy actually bills the calls
> >
> > Now let' s introduce a "hacked" terminal, and lets' s say that the
> > software on such terminal is completely free, in the sense that whatever
> > is needed we can modify it and install it.
> >
> > The question is: is it posible to define, to any extent, a mechanism
> > capable of preventing the "hacked" terminal to bypass the proxy and call
> > the "standard" endpoints witout being billed ?
> >
> > Please CC replies to gricagni@tin.it (it is easier for me to read email
> > from such mailbox here in Adelaide)
>
> Put the terminals behind a firewall which doesn't allow random UDP packets
> through.  Have the SIP proxy tell the firewall to open up the ports for each
> call's RTP streams after it processes the corresponding INVITE.  Close them
> when you see the BYE or when a session-timer expires (you'll need session
> timers for this to work).
>
> This, of course, forces you to provide application-level gateways for every
> UDP-using protocol your customers want to use.  It also leads to the
> question of why your customers won't just decamp to a provider who gives
> them proper end-to-end IP service, and only bills for true value-added
> features.
>
> --
> Jonathan Lennox
> lennox@cs.columbia.edu

--------------D90E23E9BA5A7CCEC8323071
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Jonathan,

let me say that I' m a bit tired  but, I'll try anyway... (forgive
me if I say anything terribly wrong)

Let' s even assume I can put each terminal behind a firewall, as you
described (which is something that, in our architecture, might even be
feasible):

+---+              
+------------+

| te1 |--------->|FW+Proxy1|------->+

+--+        +------------+           
|

                                                          
|

                                                          
|

+---+              
+------------+           
|

| te2 |<---------|FW+Proxy2 |<-------+

+--+        +------------+

 

Now, by assumption, TE1 is hacked: I can do whatever I want with it.

Well this network must be connected to the Internet: let's assume there
is a firewall3 towards the Net.

It is configured to let HTTP pass through as well as incoming INVITE
and ACK messages (this is necessary to interoperate with the other PNOs).

Now let me start my own business "freecalls Inc." (or, at least, "cut
price calls inc...."), also selling  terminals that

    

  • 
 incapsulate SIP in HTTP ===> [FW+Proxy1] doesn't detect the INVITE
nor the ACK
    • 


  • 
 send the packetized voice via TCP to my magic server in the Net
    • 


+---+              
+------------+

| te1 |--------->|FW+Proxy1|--------+

+--+        +------------+           
|

                                                          
|+-----+             
+----------------------------+

                                                          
| FW3 |--------->|Server (in the public Internet)+

                            
+-----+       +----------------------------+

                                                         
|

                                                          
|

+---+              
+------------+           
|

| te2 |<---------|FW+Proxy2 |--------+

+--+        +------------+

 

and that' s  it: the server performs all the required translatons
and sends all the SIP signalling and an RTP stream to TE2.

Well, I have to admit it is not very optimized, but I designed it in
half an hour....

.....I' sure our crowds of estimed hackers will be able to devise some
much more efficient solutions....

Ciao

Giuseppe

P.S.

1st optimization: you said that "This, of course, forces you to provide
application-level gateways for every UDP-using protocol your customers
want to use."

Instead of tunneling Firewall1 with HTTP+TCP, I could try with one
of such UDP-based protocols... (much better !)

 

 

 

 

 

 

 

 

Jonathan Lennox wrote:

On Tue, March 28 2000, "Giuseppe Ricagni" wrote to
"sip@lists.research.bell-labs.com" saying:

> during these days in Adelaide, I have already had the chance to discuss

> with some well known SIP experts about this topic, nevertheless I
would

> like to pose the same question to the list: maybe someone has some
other

> idea.

>

> Let' s assme that the scenaro is:

>

>    * there are a number of "standard" SIP terminals,
whose software is

>      not modifiable by the user (nor any
other application can be

>      installed)

>    * such SIP softare forces SIP to work in proxy
mode

>    * the proxy actually bills the calls

>

> Now let' s introduce a "hacked" terminal, and lets' s say that the

> software on such terminal is completely free, in the sense that whatever

> is needed we can modify it and install it.

>

> The question is: is it posible to define, to any extent, a mechanism

> capable of preventing the "hacked" terminal to bypass the proxy and
call

> the "standard" endpoints witout being billed ?

>

> Please CC replies to gricagni@tin.it (it is easier for me to read
email

> from such mailbox here in Adelaide)

Put the terminals behind a firewall which doesn't allow random UDP packets

through.  Have the SIP proxy tell the firewall to open up the
ports for each

call's RTP streams after it processes the corresponding INVITE. 
Close them

when you see the BYE or when a session-timer expires (you'll need session

timers for this to work).

This, of course, forces you to provide application-level gateways for
every

UDP-using protocol your customers want to use.  It also leads
to the

question of why your customers won't just decamp to a provider who
gives

them proper end-to-end IP service, and only bills for true value-added

features.

--

Jonathan Lennox

lennox@cs.columbia.edu



--------------D90E23E9BA5A7CCEC8323071--




From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 09:09:54 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21135
	for ; Tue, 28 Mar 2000 09:09:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id C796C52FB; Tue, 28 Mar 2000 09:05:49 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 0669C5302; Tue, 28 Mar 2000 09:05:48 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from hzsgg01.nl.lucent.com (hzsgg01.nl.lucent.com [135.85.116.11])
	by lists.research.bell-labs.com (Postfix) with SMTP id 54EDF52FB
	for ; Tue, 28 Mar 2000 09:05:11 -0500 (EST)
Received: from lucent.com (hzsgp04.nl.lucent.com) by hzsgg01.nl.lucent.com (4.1/SMI-4.1)
	id AA04477; Tue, 28 Mar 00 16:05:09 +0200
Message-Id: <38E0BC44.B20B1F13@lucent.com>
Date: Tue, 28 Mar 2000 16:05:56 +0200
From: Paul Sijben 
Organization: Lucent technologies, The Netherlands
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
Mime-Version: 1.0
To: Jonathan Lennox 
Cc: sip@lists.research.bell-labs.com
Subject: Re: Billing SIP proxy
References: <38E08F16.C3631601@italtel.it> <200003280453.XAA27441@conrail.cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jonathan,

There are some other issues involved here. 

It seems reasonnable to expect someone who put down a lot of money for a
QoS-enabled high-bandwidth network you can run SIP on (or any other
multi-media capable protocol) to want to give QoS access only to
authenticated and authorized users (so to get money from them)

Now a way to achieve this is to allow the QoS-SIP service on that network
by requiring that all users who use it to authenticate with the proxy
before using the service. That proxy can then open the firewall into the
QoS network 
and allow the (media of the) call to proceed.

BTW: Having the SIP proxy there anyway opens all kinds of options for value
added services for the service provider.

So the SIP proxy service is then bundled with the QoS service and the
firewall traversal. It may be hard to separate these issues from a business
perspective until authenticated QoS is viable.

Paul

Jonathan Lennox wrote:
> 
> On Tue, March 28 2000, "Giuseppe Ricagni" wrote to "sip@lists.research.bell-labs.com" saying:
> 
> > during these days in Adelaide, I have already had the chance to discuss
> > with some well known SIP experts about this topic, nevertheless I would
> > like to pose the same question to the list: maybe someone has some other
> > idea.
> >
> > Let' s assme that the scenaro is:
> >
> >    * there are a number of "standard" SIP terminals, whose software is
> >      not modifiable by the user (nor any other application can be
> >      installed)
> >    * such SIP softare forces SIP to work in proxy mode
> >    * the proxy actually bills the calls
> >
> > Now let' s introduce a "hacked" terminal, and lets' s say that the
> > software on such terminal is completely free, in the sense that whatever
> > is needed we can modify it and install it.
> >
> > The question is: is it posible to define, to any extent, a mechanism
> > capable of preventing the "hacked" terminal to bypass the proxy and call
> > the "standard" endpoints witout being billed ?
> >
> > Please CC replies to gricagni@tin.it (it is easier for me to read email
> > from such mailbox here in Adelaide)
> 
> Put the terminals behind a firewall which doesn't allow random UDP packets
> through.  Have the SIP proxy tell the firewall to open up the ports for each
> call's RTP streams after it processes the corresponding INVITE.  Close them
> when you see the BYE or when a session-timer expires (you'll need session
> timers for this to work).
> 
> This, of course, forces you to provide application-level gateways for every
> UDP-using protocol your customers want to use.  It also leads to the
> question of why your customers won't just decamp to a provider who gives
> them proper end-to-end IP service, and only bills for true value-added
> features.
> 
> --
> Jonathan Lennox
> lennox@cs.columbia.edu

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Message:+31 208702874			
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 09:44:01 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21532
	for ; Tue, 28 Mar 2000 09:44:00 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 16A6252F7; Tue, 28 Mar 2000 09:41:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 8181E52FA; Tue, 28 Mar 2000 09:41:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 76D5552F7
	for ; Tue, 28 Mar 2000 09:41:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 28 09:39:29 EST 2000
Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by dusty; Tue Mar 28 09:39:28 EST 2000
Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged))
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA16102
	for ; Tue, 28 Mar 2000 16:38:30 +0200 (MET DST)
Received: from mchh247e.demchh201e.icn.siemens.de ([218.1.68.147])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA02317
	for ; Tue, 28 Mar 2000 16:36:44 +0200 (MET DST)
Received: by MCHH247E with Internet Mail Service (5.5.2448.0)
	id ; Tue, 28 Mar 2000 16:40:34 +0200
Message-ID: <679076A067F2D211A8F70090274481B835E233@LNN201E>
From: Galerne Pascal 
To: "'sip@lists.research.bell-labs.com'" 
Subject: TCP communication between one client and one server.
Date: Tue, 28 Mar 2000 16:39:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Hi,
My question is about TCP communication between one client and one server and
especially about possible problems encountered when using the same
connection for several calls in opposition with the creation of one socket
connection per call.
The  RFC2543 on SIP protocol says "a single TCP connection can serve one or
more SIP transactions" does it mean that more than one call can be sent on
the same TCP connection or does it concern only all the messages of the same
call (messages with the same callId). In the first case, I see two problems:
*	If the server supports only one call for a connection, if the client
sends a second INVITE before having received the last response of the first
call, the server will received a new message with an unknown callId and goes
in failure.
*	If the server supports more than one call, after the reception of
the 200 following the BYE of the last call it may decide to close the
connection. And the client sends a new INVITE before it observes the closing
of the connection. The new INVITE will never reach the server and if the
emission system of the client is an independent process, the User Agent
client will never be informed of emission failure.

Perhaps this question has a well-known response, if someone can answer me.

Thank you. 

Pascal Galerne



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 17:30:12 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27568
	for ; Tue, 28 Mar 2000 17:30:12 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id A98CF52DB; Tue, 28 Mar 2000 17:27:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 1FAE652DE; Tue, 28 Mar 2000 17:27:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id BD6F052DB
	for ; Tue, 28 Mar 2000 17:27:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 17:26:42 EST 2000
Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Tue Mar 28 17:26:41 EST 2000
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0FS5007IBL08NH@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Tue, 28 Mar 2000 22:26:33 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with ESMTP id <0FS500601L086U@dgismtp01.wcomnet.com>;
 Tue, 28 Mar 2000 22:26:32 +0000 (GMT)
Received: from omzmta04.mcit.com ([166.37.214.10])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0FS5000OXKZTPA@dgismtp01.wcomnet.com>; Tue,
 28 Mar 2000 22:26:31 +0000 (GMT)
Received: from C25776A ([166.44.57.177])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000328222616.CEKA23055@C25776A>; Tue,
 28 Mar 2000 22:26:16 +0000
Date: Tue, 28 Mar 2000 16:26:16 -0600
From: Henry Sinnreich 
Subject: RE: Billing SIP proxy
In-reply-to: <38E0FF15.53697C00@italtel.it>
To: Giuseppe Ricagni ,
        Jonathan Lennox 
Cc: Giuseppe Ricagni , sip@lists.research.bell-labs.com
Reply-To: henry.sinnreich@wcom.com
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_e3Xvxtj86WLM3N9gTXao4A)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

This is a multi-part message in MIME format.

--Boundary_(ID_e3Xvxtj86WLM3N9gTXao4A)
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

Giuseppe,

If two parties have IP telephony clients, SIP phones for example, and the
caller knows the called IP address, nobody can prevent them legally to set
up a phone call. That phone call comes within the flat rate Internet access
charge. One way to find the the called IP address is using an instant
messenger package, or e-mail.

Henry

--Boundary_(ID_e3Xvxtj86WLM3N9gTXao4A)
Content-type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable







Giuseppe,


 


If two=20
parties have IP telephony clients, SIP phones for example, and the =
caller knows=20
the called IP address, nobody can prevent them legally to set up a phone =
call.=20
That phone call comes within the flat rate Internet access charge. One =
way to=20
find the the called IP address is using an instant messenger package, or =

e-mail.


 


Henry


--Boundary_(ID_e3Xvxtj86WLM3N9gTXao4A)--



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 18:07:57 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28028
	for ; Tue, 28 Mar 2000 18:07:56 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 86F6052DA; Tue, 28 Mar 2000 18:05:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id E657C52E0; Tue, 28 Mar 2000 18:05:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 4769952DA
	for ; Tue, 28 Mar 2000 18:05:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 18:04:04 EST 2000
Received: from hubbub.cisco.com ([171.69.11.2]) by dusty; Tue Mar 28 18:04:03 EST 2000
Received: from ORANLT (ssh.cisco.com [171.69.10.34]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id PAA04159; Tue, 28 Mar 2000 15:03:57 -0800 (PST)
From: "David Oran" 
To: "Giuseppe Ricagni" ,
        "Sip list" 
Subject: RE: Billing SIP proxy
Date: Tue, 28 Mar 2000 18:03:57 -0500
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: <38E0E174.92E16C4@tin.it>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Giuseppe Ricagni [mailto:gricagni@tin.it]
> Sent: Tuesday, March 28, 2000 11:45 AM
> To: David Oran; Sip list
> Subject: Re: Billing SIP proxy
>
>
> David,
> David Oran wrote:
> >The question is: is it posible to define, to any extent, a mechanism
> capable >of preventing the "hacked" terminal to bypass the proxy and call
> the >"standard" endpoints witout being billed ?
> There's no way to prevent one "hacked terminal" from talking to another
> "hacked terminal" directly, bypassing any proxy.
>
> Fine, this is just impossible to prevent.

> Then, I had in mind some via-header based solutions but,
> eventually, I managed to hack all of them. It looks like the one
> you propose requires some more thinking.....
> You can, at some pain, protect against is having a "standard terminal"
> answer a call from a "hacked terminal". The way you do this is when a SIP
> message comes into the UAC, ou look at the last VIA on the via list. You
> then get the IP address of that machine (either because it was on the VIA
> istelf or you called DNS to get its address) and compare that with the
> source address of the SIP message.
> I assume you mean "Source address of the IP packet containing the
> SIP message", right ?
Yes.

> If they don't match, you know somebody is
> trying to spoof you.
> mmm, let me think....
> got it !?!?!?
> 1) what if there' s a NAT in between ?
It doesn't work. Look at Jonathan's SIP with firewalls and NATs draft.
Something has to modify the DNS translations for the via's, or act as an ALG
to modify the IP addresses as they traverse the NAT so they match or the
base protocol does't work either. Any such box has to be trusted anyway.


> 2) vhat if the proxy "must be in the list", but not necessarily
> as  the last one ? (E.g. because the proxy that bills you is that
> of your "home network", and you have moved somewhere else)
The only way you can authenticate something without resorting to end-to-end
autentcation is to trust your previous hop. If the previous hop isn't
trusted you have no idea if it isn't spoofing you that your billing server
is in the via list when it in fact isn't.

> 2) on the other hand, if you  want the billing proxy always to be
> the last one (apart from all the clearinghouse-related issues
> Henry was mentioning today), it must be communicated upon
> registration. I must think about this, but I have the feeling
> that a possibility might be that  I can fool the "standard"
> terminal to re-register with me (the hacked terminal) making him
> believe I am "the proxy".
You clearly need mutual autentication with your registration server or all
sorts of other security holes open up.

> I would obviously be adding my address
> to the VIA header when inviting him.
> 3) I will think a little bit more about it
> 4) Anyway, do yo agree with me that the complexity of the "crack"
> required to "patch" such features on the "standard" terminal
> (going back therefore to the first case you mentioned) is
> definetly much smaller than that of installing a complete
> protocol from scratch on a device that was not designed to run it ?
>
Well, I think I agree with the folks wo think this is an long comlicated
road to close a hole that doesn't need to be closed. You have to bill for
something that adds value. Trying to force people to use your proxies just
so you can bill is ultimately futile in the Internet world.

|
> Best Regards
> Giuseppe
>
> If they DO match, then if the SIP UAC knows the list of SIP
> proxies which it
> trusts to deliver calls (and bill for them), the UAC either accepts or
> rejects the request appropriately.
> > Please CC replies to gricagni@tin.it (it is easier for me to read email
> from > such mailbox here in Adelaide)
> >Please let me know
> >Best Regards
> >Giuseppe




From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 19:10:04 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00106
	for ; Tue, 28 Mar 2000 19:10:03 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 6F98E52DE; Tue, 28 Mar 2000 19:07:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D727552E8; Tue, 28 Mar 2000 19:07:21 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id AEBC952DE
	for ; Tue, 28 Mar 2000 19:07:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 19:05:33 EST 2000
Received: from l3mail02.level3.com ([209.244.1.161]) by dusty; Tue Mar 28 19:05:32 EST 2000
Received: by level3.com with Internet Mail Service (5.5.2650.10)
	id ; Tue, 28 Mar 2000 17:03:25 -0700
Message-ID: 
From: Aparna.Vemuri@Level3.com
To: jbatson@pingtel.com, sip@lists.research.bell-labs.com, gricagni@tin.it
Subject: RE: Billing SIP proxy
Date: Tue, 28 Mar 2000 16:56:44 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk



Well, I think that this discussion would benefit from a more detailed
description of the context. The problem will have  different ramifications
depending on whether a corporate network or a service providers network is
being considered.

It is not unreasonable to conceive that a service provider's network does
not have any end-points, just edge-elements that aid in 'carrying' the
call.In a service provider's network,  edge-elements MUST police the calls
that go through, both entering and leaving the network. Billing is obviously
an issue only at the edges, in this case. Appropriate filtering mechanisms
that reflect certain security policies may be embedded in these
edge-elements.

>>>>>>>
I'm sympathetic to the problems of a service provider who wants to bill for 
connections.  But this question feels to me like a similar question I heard 
a few years ago when X.25 messaging vendors were asking the same question 
about SMTP/POP....  SMTP/POP kinda torpedoed existing business models (of 
charging for email transport).  SIP may pose similar challenges for 
"pay-for-connection" business models.  Fortunately, it gives service 
providers a nifty mechanism to create new services to replace that lost 
revenue....
<<<<<<<<


Service providers can not only provide directory services, for those who may
want to receive calls, but also guarantee QoS. And most importantly, they
allow  PSTN-access. And, BTW, such calls are not immune to the described
security threats either.

In an enterprise network where SIP services are available internally, calls
that do not straddle the boundaries of the network do not really pose a
problem. 



Aparna V.
Level (3) Communications.

-----Original Message-----
From: Jay Batson [mailto:jbatson@pingtel.com]
Sent: Monday, March 27, 2000 9:25 PM
To: sip@lists.research.bell-labs.com; gricagni@tin.it
Subject: Re: Billing SIP proxy


IMHO, there will always be UAs that do not want to be forced against their 
desire to use a particular proxy.  If I'm a died-in-the-wool Net-Head, I 
may very well be happy with:

- making a call from my Pingtel phone (at sip:jbatson@pingtel.com) to 
Henning's SIP address ( at sip:hgs@cs.columbia.edu);

- having my Pingtel phone sends the INVITE directly to Henning's proxy 
(without my service provider being involved);

- having everything going across the public Internet, getting "best 
efforts" delivery of everything;

- which doesn't require any service provider anywhere to know about or care 
about the call.

Which, of course, is exactly what SIP does now, thank you.  So I'll be very 
happy not to see us "break" the swell protocol we have... ;-)

I
Cheers
-jb


>Now let' s introduce a "hacked" terminal, and lets' s say that the 
>software on such terminal is completely free, in the sense that whatever 
>is needed we can modify it and install it.
>
>The question is: is it posible to define, to any extent, a mechanism 
>capable of preventing the "hacked" terminal to bypass the proxy and call 
>the "standard" endpoints witout being billed ?




From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 19:52:00 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00661
	for ; Tue, 28 Mar 2000 19:52:00 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id CC9A252E0; Tue, 28 Mar 2000 19:49:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 5034352F1; Tue, 28 Mar 2000 19:49:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 6C1BC52E0
	for ; Tue, 28 Mar 2000 19:49:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 19:49:02 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Tue Mar 28 19:49:02 EST 2000
Received: from dynamicsoft.com (1Cust221.tnt1.adl1.da.uu.net [210.84.192.221])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA18710;
	Tue, 28 Mar 2000 19:50:06 -0500 (EST)
Message-ID: <38E14B95.675C1C99@dynamicsoft.com>
Date: Tue, 28 Mar 2000 19:17:25 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Oran 
Cc: Giuseppe Ricagni ,
        Sip list 
Subject: Re: Billing SIP proxy
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



David Oran wrote:
> 
> Well, I think I agree with the folks wo think this is an long comlicated
> road to close a hole that doesn't need to be closed. You have to bill for
> something that adds value. Trying to force people to use your proxies just
> so you can bill is ultimately futile in the Internet world.

I agree 100%. You cannot bill for services you don't actually provide.

Even blocking UDP packets at a firewall unless opened through control in
a SIP proxy will not force people to use the proxy. As long as there is
*any* service which you let out through your firewall (like HTTP), I can
tunnel my own service on top of that. HTTP decapsulating proxies
external to the firewall can unwrap the SIP and RTP, and send them to
the final destination. Thus, a "hacked" UA inside the firewall (where
that hacked UA is perhaps software downloaded from a "free SIP" provider
running this HTTP decapsulator) can still call any normal SIP UA outside
the firewall for free. 

Now, if you are providing some value add (such as QoS), requiring people
to call through your proxy to access that service is reasonable. If they
don't, well, they just won't get QoS.

-Jonathan R.


-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com





From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 19:55:36 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00680
	for ; Tue, 28 Mar 2000 19:55:36 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 654F652F1; Tue, 28 Mar 2000 19:51:48 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A0B2652F2; Tue, 28 Mar 2000 19:51:46 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 3D77B52F1
	for ; Tue, 28 Mar 2000 19:51:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 28 19:50:00 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Tue Mar 28 19:49:59 EST 2000
Received: from dynamicsoft.com (1Cust221.tnt1.adl1.da.uu.net [210.84.192.221])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA18726;
	Tue, 28 Mar 2000 19:50:57 -0500 (EST)
Message-ID: <38E14DAE.78A1D4F1@dynamicsoft.com>
Date: Tue, 28 Mar 2000 19:26:22 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Galerne Pascal 
Cc: "'sip@lists.research.bell-labs.com'" 
Subject: Re: TCP communication between one client and one server.
References: <679076A067F2D211A8F70090274481B835E233@LNN201E>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Galerne Pascal wrote:
> 
> Hi,
> My question is about TCP communication between one client and one server and
> especially about possible problems encountered when using the same
> connection for several calls in opposition with the creation of one socket
> connection per call.
> The  RFC2543 on SIP protocol says "a single TCP connection can serve one or
> more SIP transactions" does it mean that more than one call can be sent on
> the same TCP connection or does it concern only all the messages of the same
> call (messages with the same callId). 

It can be for any number of calls.

>In the first case, I see two problems:
> *       If the server supports only one call for a connection, if the client
> sends a second INVITE before having received the last response of the first
> call, the server will received a new message with an unknown callId and goes
> in failure.

Huh? If an INVITE is received with an unrecognized Call-ID, its a new
call, whether its over an existing TCP connection, a new one, or UDP.


> *       If the server supports more than one call, after the reception of
> the 200 following the BYE of the last call it may decide to close the
> connection. And the client sends a new INVITE before it observes the closing
> of the connection. The new INVITE will never reach the server and if the
> emission system of the client is an independent process, the User Agent
> client will never be informed of emission failure.

Then it opens a new connection. There is really no tie between a TCP
connection and a call. If a client wants to send an INVITE to address X,
and it has a TCP connection open to X, use it. If there is no connection
to X, open one.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com





From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 20:36:07 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01031
	for ; Tue, 28 Mar 2000 20:36:07 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id BF99D52F2; Tue, 28 Mar 2000 20:33:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 2D92652F6; Tue, 28 Mar 2000 20:33:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 5A35452F2
	for ; Tue, 28 Mar 2000 20:33:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 20:31:35 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Tue Mar 28 20:31:34 EST 2000
Received: from dynamicsoft.com (1Cust221.tnt1.adl1.da.uu.net [210.84.192.221])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA18773;
	Tue, 28 Mar 2000 20:28:43 -0500 (EST)
Message-ID: <38E15DC6.17EAFEB8@dynamicsoft.com>
Date: Tue, 28 Mar 2000 20:35:02 -0500
From: Jonathan Rosenberg 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Donovan, Steven R." 
Cc: "'Anders Kristensen'" ,
        Henning Schulzrinne ,
        SIP 
Subject: Re: Session timer comments
References: <75C79E507864D3118AFC00805FEAB7D83493A2@ripexch001.mcit.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Donovan, Steven R." wrote:
> 
> Anders Kristensen wrote:
> 
> >  o The crashed UA may have had a route associated with the
> > leg. Allowing
> > a re-INVITE to set up a leg in the crashed UAS as if it was
> > an original
> > INVITE ignores the fact that subsequent requests should follow a route
> > established prior to the crash.
> >
> 
> This is addressed by an addition to 2543bis:
> 
>   "Note that proxy servers have to add Record-Route headers to each
>    request as long as they want to be "visited" by the next request
>    for the call leg."
> 
> The only way for a proxy to insure that it will be a part of all requests is
> to insert the Record-Route header into all requests, even those that have a
> Route header.

I think this may cause interop problems. Much as I'd like to add this,
it means any old proxy that doesn't insert REcord-Route is going to get
booted off the signaling path. That seems like a problem. 

Beyond that, the other problem with re-establishing the session at the
crashed and rebooted UA is the CSeq space. It will loose track of the
CSeq number it had been using in the other direction. Thus, any messages
it sends may be rejected by the UA on the other side as being out of
order. This, too, can be fixed if you are careful about choosing CSeq
numbers. The spec recommends, I believe, choosing them based on a local
clock. This would actually mean that a UA that crashes and reboots would
still be able to send requests with the right CSeq.

However, a more interesting problem is the following. Lets say A and B
are talking, and B crashes and reboots. Now, A sends a re-invite to B. B
rejects the re-INVITE, which it believes is an initial INVITE, and thus
it thinks there is no call. A thinks the rejection is for a re-INVITE,
and thus still believes the call is up. Session timer is meant to deal
with exactly these kinds of things, and it would detect this condition.
But, any other ideas on possible solutions outside of session timer? 

Stepping back a moment, this problem is rooted in the simple fact that
we use INVITE for both initiation and modification. That will work, I
believe, if the rules for handling and responding to INVITE are
absolutely, positively no different if you are in, or not in a call. As
soon as the behavior is different because its a re-INVITE, thats where
oddball problems like this come up. For example, if the response to a
re-INVITE is always 200 OK so long as the session is still up, and a
response of 400 means the session is not active (as it is for a normal
INVITE), this crash and reboot problem above will not happen.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com



From owner-sip-outgoing@lists.research.bell-labs.com  Tue Mar 28 22:16:06 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02578
	for ; Tue, 28 Mar 2000 22:16:06 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 61A8252F6; Tue, 28 Mar 2000 22:13:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id D6D3052F9; Tue, 28 Mar 2000 22:13:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id D222252F6
	for ; Tue, 28 Mar 2000 22:13:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 22:12:47 EST 2000
Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Tue Mar 28 22:12:46 EST 2000
Received: from vovida.com (static-8-13.ietf.connect.com.au [169.208.8.13])
	by repulse.cnchost.com
	id WAA29906; Tue, 28 Mar 2000 22:12:42 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38E174DF.5F0B6CBB@vovida.com>
Date: Tue, 28 Mar 2000 19:13:36 -0800
From: Sunitha Kumar 
Organization: Vovida Networks
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: zh,zh-CN,en
MIME-Version: 1.0
To: "'sip@lists.research.bell-labs.com'" 
Subject: typo or error in the call flow examples draft.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi:

I noticed  the user=phone is outside <> in
draft-ietf-sip-call-flows-00.txt
Just thought I could bring it to the author's notice.

4.1.1 p.77

   F1 INVITE A -> Proxy 1

   INVITE sip:+1-972-555-2222@ss1.wcom.com;user=phone  SIP/2.0
   Via: SIP/2.0/UDP here.com:5060
   From: BigGuy ;user=phone
   To: LittleGuy ;user=phone
   :
   :
   F2 (100 Trying) Proxy 1 -> User A

   SIP/2.0 100 Trying
   Via: SIP/2.0/UDP here.com:5060
   From: BigGuy ;user=phone
   To: LittleGuy ;user=phone
   :
   :
   F3 INVITE Proxy 1 -> NGW 1

   INVITE sip:+1-972-555-2222@ngw1.wcom.com;user=phone SIP/2.0
   Via: SIP/2.0/UDP ss1.wcom.com:5060
   Via: SIP/2.0/UDP here.com:5060
   Record-Route: 
   From: BigGuy ;user=phone
   To: LittleGuy ;user=phone
   :
   :
   F4 (100 Trying) NGW 1 -> Proxy 1

   SIP/2.0 100 Trying
   Via: SIP/2.0/UDP ss1.wcom.com:5060
   From: BigGuy ;user=phone
   To: LittleGuy ;user=phone
   :
   :
   F7 183 Session Progress NGW 1 -> Proxy 1

   SIP/2.0 183 Session Progress
   Via: SIP/2.0/UDP ss1.wcom.com:5060
   Via: SIP/2.0/UDP here.com:5060
   From: BigGuy ;user=phone
   To: LittleGuy ;user=phone
   :
   :
   F8 183 Session Progress Proxy 1 -> User A

   SIP/2.0 183 Session Progress
   Via: SIP/2.0/UDP here.com:5060
   From: BigGuy ;user=phone
   To: LittleGuy ;user=phone

And there are several more.
The same thing happens in 4.1.2, 4.1.3, etc.

Thanks
sunitha




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 00:24:12 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01459
	for ; Thu, 30 Mar 2000 00:24:11 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 8BD0052AB; Thu, 30 Mar 2000 00:18:10 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id F3CDD52BB; Thu, 30 Mar 2000 00:18:09 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id BE73052AB
	for ; Thu, 30 Mar 2000 00:17:09 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 00:15:36 EST 2000
Received: from dgesmtp01.wcom.com ([199.249.16.16]) by dusty; Thu Mar 30 00:15:35 EST 2000
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FS700JB2YLO4I@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Thu, 30 Mar 2000 05:15:24 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with ESMTP id <0FS700B01YLNPZ@pmismtp02.wcomnet.com> for
 sip@lists.research.bell-labs.com; Thu, 30 Mar 2000 05:15:24 +0000 (GMT)
Received: from omzmta04.mcit.com ([166.37.214.10])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0FS7008K2YLNN7@pmismtp02.wcomnet.com> for
 sip@lists.research.bell-labs.com; Thu, 30 Mar 2000 05:15:23 +0000 (GMT)
Received: from dwillispc8 ([166.44.162.169])
 by omzmta04.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000330051522.CQNJ663@dwillispc8> for
 ; Thu, 30 Mar 2000 05:15:22 +0000
Date: Wed, 29 Mar 2000 23:14:41 -0600
From: Dean Willis 
Subject: WG Supplemental Web Server revised
To: IETF SIP 
Message-id: <004101bf9a06$da2fa4e0$cdc0d0a9@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


Rather than continuing to fight the silly DSL line feeding my house, I have
just pointed www.softarmor.com at the commercial web server that is
currently serving our supplemental web.

So, you can use either:

www.softarmor.com/sipwg
or
www.greycouncil.com/sipwg

to get to the supplemental page.

The former (softarmor) is the preferred mechanism, as I have direct control
of that DNS zone and can make further adjustments as necessary without
impacting the URL.

--
Dean Willis
MCI WorldCom Engineering
972-729-4162, v772-4162




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 01:22:03 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02521
	for ; Thu, 30 Mar 2000 01:22:01 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3640052B6; Thu, 30 Mar 2000 01:19:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id A63E952C4; Thu, 30 Mar 2000 01:19:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id C24B152B6
	for ; Thu, 30 Mar 2000 01:19:04 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 30 01:18:05 EST 2000
Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Thu Mar 30 01:18:05 EST 2000
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11])
	by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id IAA01526
	for ; Thu, 30 Mar 2000 08:18:02 +0200 (MET DST)
Received: from ericsson.com (kipe163.eraj.ericsson.se [147.214.68.163])
	by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id IAA03500
	for ; Thu, 30 Mar 2000 08:17:59 +0200 (MET DST)
Message-ID: <38E26A08.1DEEB68E@ericsson.com>
Date: Wed, 29 Mar 2000 22:39:37 +0200
From: Stephen Terrill 
Organization: L.M. Ericsson
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: Re: Question on RTP
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

interesting implications on resource reservation ... ?

..//Steve

"Fairlie-Cuninghame, Robert" wrote:

>                 --> Kimmo.Rantanen@lmf.ericsson.se writes:
>                 >I like to add one more question:
>                 >Is it absolutely necessary that both direction use the same
> type of
>                 >codec ?
>
>                 No.
>
>                 This is rather undesirable for vocoders or implementations
> employing advanced echo cancellation, intelligent jitter buffer management
> or a host of other DSP or voice-related properties.
>
>                 From my reading of the RFC, it is also equally possible for
> either side to chop-and-change between vocoders at any point in time
> (without SIP message exchange). Supporting this mixing and splicing of
> vocoders significantly complicates the playback engine - the ability will
> most likely be unsupported on simpler implementations or at best may cause
> small audio glitches.
>
>                 It would be nice if the caller could force the callee to
> agree on a single common vocoder if it doesn't support the use of multiple
> vocoders. [Making the SDP session closer to a true two-way media exchange
> rather than simply two disjoint vocoder packet flows in each direction.]
>
>                 One approach might be to place an updated SDP body in the
> ACK where the SDP body has only one media format selected. The RFC currently
> prohibits changing the SDP body in the ACK (unless the INVITE had no SDP
> body). Does changing the body introduce any major problems or
> inconsistencies ?
>
>                 Furthermore, IMO it would be desirable if the callee could
> indicate their vocoder preference by ordering the list of RTP media format
> values in the 183/200 response.
>
>                 How have other people tackled this problem ? Are there any
> drafts or FAQ on these subjects.
>
>                 Cheers,
>
>                 Robert.
>






From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 02:34:11 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13642
	for ; Thu, 30 Mar 2000 02:34:11 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id B0D9252BB; Thu, 30 Mar 2000 02:31:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 2FFCA52C8; Thu, 30 Mar 2000 02:31:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id C884252BB
	for ; Thu, 30 Mar 2000 02:31:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 02:30:41 EST 2000
Received: from dgesmtp01.wcom.com ([199.249.16.16]) by dusty; Thu Mar 30 02:30:41 EST 2000
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0FS8002BZ4V39E@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Thu, 30 Mar 2000 07:30:39 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with ESMTP id <0FS8003014V393@pmismtp02.wcomnet.com> for
 sip@lists.research.bell-labs.com; Thu, 30 Mar 2000 07:30:39 +0000 (GMT)
Received: from omzmta03.mcit.com ([166.37.214.9])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0FS80021P4V3ZI@pmismtp02.wcomnet.com> for
 sip@lists.research.bell-labs.com; Thu, 30 Mar 2000 07:30:39 +0000 (GMT)
Received: from dwillispc8 ([166.44.162.169])
 by omzmta03.mcit.com (InterMail v03.02.05 118 121 101)
 with SMTP id <20000330073038.HXDB14422@dwillispc8> for
 ; Thu, 30 Mar 2000 07:30:38 +0000
Date: Thu, 30 Mar 2000 01:29:55 -0600
From: Dean Willis 
Subject: SIP-H.323 Desig Team page created
To: IETF SIP 
Message-id: <000201bf9a19$becb07e0$cdc0d0a9@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


There was a BOF for SIP and H.323 interworking here in Adelaide. Based on
the results, the ADs suggested forming up a design team in the SIP WG to
carry this work forward. I've started up a team web page adjacent to the
other SIPWG design teams at:

http://www.softarmor.com/sipwg/teams/sip-h323/index.html

Not much content there yet, but will be posting BOF slides and meeting
minutes there soon. If you're working in this area and want your name kisted
here, please let me know.

Thanks, all!

--
Dean Willis
SIP WG co-chair.




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 09:22:24 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16673
	for ; Thu, 30 Mar 2000 09:22:23 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 8EC7B52C4; Thu, 30 Mar 2000 09:19:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 0D05152D4; Thu, 30 Mar 2000 09:19:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 0BA1052C4
	for ; Thu, 30 Mar 2000 09:19:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 09:18:48 EST 2000
Received: from dgesmtp02.wcom.com ([199.249.16.17]) by dusty; Thu Mar 30 09:18:47 EST 2000
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0FS800CBGNR43K@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Thu, 30 Mar 2000 14:18:40 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with ESMTP id <0FS800A01NR4DZ@pmismtp01.wcomnet.com>;
 Thu, 30 Mar 2000 14:18:40 +0000 (GMT)
Received: from omzmta01.mcit.com ([166.37.214.7])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0FS80087INR3HR@pmismtp01.wcomnet.com>; Thu,
 30 Mar 2000 14:18:40 +0000 (GMT)
Received: from wcom.com ([166.33.132.111])
 by omzmta01.mcit.com (InterMail v03.02.05 118 121 101)
 with ESMTP id <20000330141839.OLJN29675@wcom.com>; Thu,
 30 Mar 2000 14:18:39 +0000
Date: Thu, 30 Mar 2000 08:19:29 -0600
From: Alan Johnston 
Subject: Re: typo or error in the call flow examples draft.
To: Sunitha Kumar 
Cc: "'sip@lists.research.bell-labs.com'" 
Message-id: <38E36271.1F630EF8@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <38E174DF.5F0B6CBB@vovida.com>
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sunitha,

You are correct - this is a typo.  The user=phone parameter is part of the URL
and belongs inside the <>.

Thanks for pointing it out - it will be corrected.

Alan Johnston
MCI WorldCom

Sunitha Kumar wrote:
> 
> Hi:
> 
> I noticed  the user=phone is outside <> in
> draft-ietf-sip-call-flows-00.txt
> Just thought I could bring it to the author's notice.
> 
> 4.1.1 p.77
> 
>    F1 INVITE A -> Proxy 1
> 
>    INVITE sip:+1-972-555-2222@ss1.wcom.com;user=phone  SIP/2.0
>    Via: SIP/2.0/UDP here.com:5060
>    From: BigGuy ;user=phone
>    To: LittleGuy ;user=phone
>    :
>    :
>    F2 (100 Trying) Proxy 1 -> User A
> 
>    SIP/2.0 100 Trying
>    Via: SIP/2.0/UDP here.com:5060
>    From: BigGuy ;user=phone
>    To: LittleGuy ;user=phone
>    :
>    :
>    F3 INVITE Proxy 1 -> NGW 1
> 
>    INVITE sip:+1-972-555-2222@ngw1.wcom.com;user=phone SIP/2.0
>    Via: SIP/2.0/UDP ss1.wcom.com:5060
>    Via: SIP/2.0/UDP here.com:5060
>    Record-Route: 
>    From: BigGuy ;user=phone
>    To: LittleGuy ;user=phone
>    :
>    :
>    F4 (100 Trying) NGW 1 -> Proxy 1
> 
>    SIP/2.0 100 Trying
>    Via: SIP/2.0/UDP ss1.wcom.com:5060
>    From: BigGuy ;user=phone
>    To: LittleGuy ;user=phone
>    :
>    :
>    F7 183 Session Progress NGW 1 -> Proxy 1
> 
>    SIP/2.0 183 Session Progress
>    Via: SIP/2.0/UDP ss1.wcom.com:5060
>    Via: SIP/2.0/UDP here.com:5060
>    From: BigGuy ;user=phone
>    To: LittleGuy ;user=phone
>    :
>    :
>    F8 183 Session Progress Proxy 1 -> User A
> 
>    SIP/2.0 183 Session Progress
>    Via: SIP/2.0/UDP here.com:5060
>    From: BigGuy ;user=phone
>    To: LittleGuy ;user=phone
> 
> And there are several more.
> The same thing happens in 4.1.2, 4.1.3, etc.
> 
> Thanks
> sunitha



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 16:07:18 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21621
	for ; Thu, 30 Mar 2000 16:07:16 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 7FDF752BB; Thu, 30 Mar 2000 16:03:45 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id EBA5C52AB; Thu, 30 Mar 2000 16:03:44 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 9B79252BB
	for ; Thu, 30 Mar 2000 16:03:11 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 16:02:55 EST 2000
Received: from grimy.research.bell-labs.com ([204.178.16.57]) by dusty; Thu Mar 30 16:02:50 EST 2000
Received: from mgw-x2.nokia.com ([131.228.20.22]) by grimy; Thu Mar 30 15:52:47 EST 2000
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id WAA13448
	for ; Thu, 30 Mar 2000 22:49:22 +0200 (EET)
From: Cliff.Harris@nokia.com
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183])
	by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id WAA19826
	for ; Thu, 30 Mar 2000 22:49:21 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0)
	id ; Thu, 30 Mar 2000 14:49:20 -0600
Message-ID: 
To: sip@lists.research.bell-labs.com
Subject: SIP INFO: What is "mid-session"; sessions w/o media
Date: Thu, 30 Mar 2000 14:47:34 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

1. The draft on the INFO method says that the INFO method may be used
"mid-session"; exactly what that means is not clear to me. Does it mean that
the UAC may send an INFO right after sending an INVITE, and the UAS may send
an INFO right after receiving an INVITE?

2. Is it possible to create a session without a media stream, solely for the
purpose of sending one or more INFOs, and if so, is there a standard or
preferred way of doing so?

Thanks,

Cliff Harris



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 16:10:26 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21684
	for ; Thu, 30 Mar 2000 16:10:25 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 4834052D4; Thu, 30 Mar 2000 16:03:55 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B966552C4; Thu, 30 Mar 2000 16:03:49 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 0F1DB52C4
	for ; Thu, 30 Mar 2000 16:03:14 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 16:02:48 EST 2000
Received: from mgw-x1.nokia.com ([131.228.20.21]) by dusty; Thu Mar 30 16:02:47 EST 2000
Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60])
	by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id XAA05950
	for ; Thu, 30 Mar 2000 23:02:37 +0200 (EET)
From: Cliff.Harris@nokia.com
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183])
	by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id XAA24122
	for ; Thu, 30 Mar 2000 23:02:36 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0)
	id ; Thu, 30 Mar 2000 15:02:35 -0600
Message-ID: 
To: sip@lists.research.bell-labs.com
Subject: Teardown sequence for SIP-to-ISDN call
Date: Thu, 30 Mar 2000 15:00:49 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

In "SIP Telephony Call Flow Examples," the teardown sequence for a
SIP-to-ISDN call (pp. 83-84) is shown as 

       |     BYE F24    |                |
       |--------------->|                |
       |     200 F25    |                |
       |<---------------| DISConnect F27 |
       |                |--------------->|
       |                |   RELease F28  |
       |                |<---------------|
       |                | RELease COM F29|
       |                |--------------->|
       |                |                |

I was wondering why this was selected instead of 

       |     BYE        |                |
       |--------------->|                |
       |                | DISConnect     |
       |                |--------------->|
       |                |   RELease      |
       |                |<---------------|
       |     200        |                |
       |<---------------|                |
       |                | RELease COM    |
       |                |--------------->|

Thanks,

Cliff Harris



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 16:49:56 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21967
	for ; Thu, 30 Mar 2000 16:49:54 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id A53F552B6; Thu, 30 Mar 2000 16:47:24 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 2670552C4; Thu, 30 Mar 2000 16:47:24 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id BA38052B6
	for ; Thu, 30 Mar 2000 16:47:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 16:45:48 EST 2000
Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Thu Mar 30 16:45:48 EST 2000
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0FS9007198G7TJ@firewall.mcit.com> for
 sip@lists.research.bell-labs.com; Thu, 30 Mar 2000 21:45:43 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with ESMTP id <0FS900K018G6KK@pmismtp02.wcomnet.com>;
 Thu, 30 Mar 2000 21:45:43 +0000 (GMT)
Received: from omta3.mcit.com ([166.37.204.5])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0FS900HOC8G633@pmismtp02.wcomnet.com>; Thu,
 30 Mar 2000 21:45:42 +0000 (GMT)
Received: from wcom.com ([166.33.132.111])
 by omta3.mcit.com (InterMail v03.02.05 118 121 101)
 with ESMTP id <20000330214559.MGFC6091@wcom.com>; Thu,
 30 Mar 2000 21:45:59 +0000
Date: Thu, 30 Mar 2000 15:46:31 -0600
From: Alan Johnston 
Subject: Re: Teardown sequence for SIP-to-ISDN call
To: Cliff.Harris@nokia.com
Cc: sip@lists.research.bell-labs.com
Message-id: <38E3CB37.57E08C4D@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.51 [en] (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: 
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

Cliff,

An older version of the document had the explanation for this - I should add it
back in.

The reason for this flow is that you do not want the teardown of resources on
one network dependent on the teardown of resources on the other network.  Once
the BYE is received by the Gateway, the call is over so all resources should be
freed up as soon as possible.  If the teardown failed for some reason on the
ISDN side (due to a network problem, for example) you would not want the IP
resources including the RTP port left hanging.

Resources in Section 5 are freed up in the same way, with the RLC not dependent
on the receipt of a 200 OK in 5.1.1 on page 119, for example.

Alan Johnston
MCI WorldCom

Cliff.Harris@nokia.com wrote:
> 
> In "SIP Telephony Call Flow Examples," the teardown sequence for a
> SIP-to-ISDN call (pp. 83-84) is shown as
> 
>        |     BYE F24    |                |
>        |--------------->|                |
>        |     200 F25    |                |
>        |<---------------| DISConnect F27 |
>        |                |--------------->|
>        |                |   RELease F28  |
>        |                |<---------------|
>        |                | RELease COM F29|
>        |                |--------------->|
>        |                |                |
> 
> I was wondering why this was selected instead of
> 
>        |     BYE        |                |
>        |--------------->|                |
>        |                | DISConnect     |
>        |                |--------------->|
>        |                |   RELease      |
>        |                |<---------------|
>        |     200        |                |
>        |<---------------|                |
>        |                | RELease COM    |
>        |                |--------------->|
> 
> Thanks,
> 
> Cliff Harris



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 17:17:57 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22420
	for ; Thu, 30 Mar 2000 17:17:56 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 8EE4152BB; Thu, 30 Mar 2000 17:15:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 1015152C4; Thu, 30 Mar 2000 17:15:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id A099652BB
	for ; Thu, 30 Mar 2000 17:15:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 17:14:21 EST 2000
Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Thu Mar 30 17:14:20 EST 2000
Received: from vovida.com (static-8-13.ietf.connect.com.au [169.208.8.13])
	by repulse.cnchost.com
	id RAA20022; Thu, 30 Mar 2000 17:14:16 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38E323BC.7889AFC8@vovida.com>
Date: Thu, 30 Mar 2000 01:51:57 -0800
From: Sunitha Kumar 
Organization: Vovida Networks
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: zh,zh-CN,en
MIME-Version: 1.0
To: "'sip@lists.research.bell-labs.com'" 
Subject: inconsistancy in the sip_2543bis_00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


I noticed an inconsistancy between 10.4.1 ( if the client recives a
provisional response , it continues to retransmit the request) and 10.5
( should stop retransmission after the first provisional response).
also, in 10.4.1, it is given that
it is retransmitted for 11 times. Should this not be 7 times?

sunitha





From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 17:30:48 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22564
	for ; Thu, 30 Mar 2000 17:30:48 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id C71BB52C8; Thu, 30 Mar 2000 17:27:38 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 11BA752D5; Thu, 30 Mar 2000 17:27:37 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9])
	by lists.research.bell-labs.com (Postfix) with SMTP id 10B6E52C4
	for ; Thu, 30 Mar 2000 17:27:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Mar 30 17:26:55 EST 2000
Received: from redball.dynamicsoft.com ([216.173.40.51]) by dusty; Thu Mar 30 17:26:54 EST 2000
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA22479;
	Thu, 30 Mar 2000 17:28:01 -0500 (EST)
Message-ID: <38E3D450.93191DE@dynamicsoft.com>
Date: Thu, 30 Mar 2000 17:25:20 -0500
From: Igor Slepchin 
Organization: dynamicsoft
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Sunitha Kumar 
Cc: "'sip@lists.research.bell-labs.com'" 
Subject: Re: inconsistancy in the sip_2543bis_00.txt
References: <38E323BC.7889AFC8@vovida.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

10.4.1 describes reliability of non-INVITE requests, 10.5.1 - that of
INVITE requests. As you've noticed, the mechanisms are necessarily
different.

---
Igor Slepchin


Sunitha Kumar wrote:
> 
> I noticed an inconsistancy between 10.4.1 ( if the client recives a
> provisional response , it continues to retransmit the request) and 10.5
> ( should stop retransmission after the first provisional response).
> also, in 10.4.1, it is given that
> it is retransmitted for 11 times. Should this not be 7 times?
> 
> sunitha



From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 17:32:57 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22659
	for ; Thu, 30 Mar 2000 17:32:56 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 3C48252D6; Thu, 30 Mar 2000 17:27:39 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 786ED52C4; Thu, 30 Mar 2000 17:27:37 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id C5DA252C8
	for ; Thu, 30 Mar 2000 17:27:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 17:25:37 EST 2000
Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Thu Mar 30 17:25:36 EST 2000
Received: from vovida.com (static-8-13.ietf.connect.com.au [169.208.8.13])
	by repulse.cnchost.com
	id RAA23693; Thu, 30 Mar 2000 17:25:26 -0500 (EST)
	[ConcentricHost SMTP Relay 1.8]
Message-ID: <38E3D498.217FF0EA@vovida.com>
Date: Thu, 30 Mar 2000 14:26:32 -0800
From: Sunitha Kumar 
Organization: Vovida Networks
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; I)
X-Accept-Language: zh,zh-CN,en
MIME-Version: 1.0
To: Cliff.Harris@nokia.com
Cc: sip@lists.research.bell-labs.com
Subject: Re: SIP INFO: What is "mid-session"; sessions w/o media
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Cliff.Harris@nokia.com wrote:

> 1. The draft on the INFO method says that the INFO method may be used
> "mid-session"; exactly what that means is not clear to me. Does it mean that
> the UAC may send an INFO right after sending an INVITE, and the UAS may send
> an INFO right after receiving an INVITE?

INFO msg is used to convey something more about the session. Hence, the
requirement is that this msg has to match an existing callLeg, else it will be
rejected at the UAS.
So, you can send INFO once the callLeg is established, i.e after sending an
INVITE.


>
>
> 2. Is it possible to create a session without a media stream, solely for the
> purpose of sending one or more INFOs, and if so, is there a standard or
> preferred way of doing so?
>

I read somewhere that you can send INVITE without including the media details
(i.e without the SDP). If that is correct, then you can send INFO after this
INVITE.
So, in essence, the media stream is not (yet) opened at this time.

>

Hope that helps.
sunitha

>
> Thanks,
>
> Cliff Harris




From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 18:42:06 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23489
	for ; Thu, 30 Mar 2000 18:42:06 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 968C152D4; Thu, 30 Mar 2000 18:39:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 14BC052D5; Thu, 30 Mar 2000 18:39:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 66B8C52D4
	for ; Thu, 30 Mar 2000 18:39:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 18:37:31 EST 2000
Received: from illyana.qualcomm.com ([129.46.2.83]) by dusty; Thu Mar 30 18:37:31 EST 2000
Received: from localhost (mwisdom@localhost) by illyana.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id PAA29100 for ; Thu, 30 Mar 2000 15:37:29 -0800 (PST)
Date: Thu, 30 Mar 2000 15:37:29 -0800 (PST)
From: Mark Wisdom 
To: SIP Mailing List 
Subject: Availability of RFC2543bis in ASCII
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

RFC2543bis is available in PDF and PostScript formats, i.e.:
 
  http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-2543bis-00.pdf
  http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-2543bis-00.ps 
 
But I can't find a plain ASCII version anywhere. If an ASCII version
exists, can someone please tell us where we can find it (some of you
have been referring to sip_2543bis_00.txt). If not, can one please be
made available. I like having an ASCII version for quick grep-style
scanning of information.

Thanks,
Mark





From owner-sip-outgoing@lists.research.bell-labs.com  Thu Mar 30 23:44:07 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27971
	for ; Thu, 30 Mar 2000 23:44:07 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id AED3152C4; Thu, 30 Mar 2000 23:41:22 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 2D15B52D5; Thu, 30 Mar 2000 23:41:22 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 76E9F52C4
	for ; Thu, 30 Mar 2000 23:41:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 23:40:04 EST 2000
Received: from exchangesvr.nuera.com ([204.216.240.124]) by dusty; Thu Mar 30 23:40:04 EST 2000
Received: by exchangesvr.nuera.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 30 Mar 2000 20:40:10 -0800
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Sunitha Kumar'" 
Cc: sip@lists.research.bell-labs.com
Subject: RE: SIP INFO: What is "mid-session"; sessions w/o media
Date: Thu, 30 Mar 2000 20:40:09 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk

Are you saying you can send an INFO _immediately_ after sending the INVITE
or must you wait for a provisional response or even a final response ?

Robert.

-----Original Message-----
From:	Sunitha Kumar [mailto:skumar@vovida.com]
Sent:	Friday, March 31, 2000 6:27 AM
To:	Cliff.Harris@nokia.com
Cc:	sip@lists.research.bell-labs.com
Subject:	Re: SIP INFO: What is "mid-session"; sessions w/o media



Cliff.Harris@nokia.com wrote:

> 1. The draft on the INFO method says that the INFO method may be used
> "mid-session"; exactly what that means is not clear to me. Does it mean
that
> the UAC may send an INFO right after sending an INVITE, and the UAS may
send
> an INFO right after receiving an INVITE?

INFO msg is used to convey something more about the session. Hence, the
requirement is that this msg has to match an existing callLeg, else it will
be
rejected at the UAS.
So, you can send INFO once the callLeg is established, i.e after sending an
INVITE.


>
>
> 2. Is it possible to create a session without a media stream, solely for
the
> purpose of sending one or more INFOs, and if so, is there a standard or
> preferred way of doing so?
>

I read somewhere that you can send INVITE without including the media
details
(i.e without the SDP). If that is correct, then you can send INFO after this
INVITE.
So, in essence, the media stream is not (yet) opened at this time.

>

Hope that helps.
sunitha

>
> Thanks,
>
> Cliff Harris




From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 31 09:15:10 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13830
	for ; Fri, 31 Mar 2000 09:15:10 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 7356D52D4; Fri, 31 Mar 2000 09:05:28 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id 86B9452D6; Fri, 31 Mar 2000 09:05:27 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id AF03352F2
	for ; Tue, 28 Mar 2000 02:35:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 02:34:24 EST 2000
Received: from mail.iagu.net ([203.32.153.69]) by dusty; Tue Mar 28 02:34:23 EST 2000
Received: from dhcp-32-247.ietf.connect.com.au [169.208.32.247]
  by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id RAA03558
  return ;
  Tue, 28 Mar 2000 17:02:59 +0930 (CST)
Message-ID: <38E0C9B6.1D7685CF@tin.it>
Date: Tue, 28 Mar 2000 17:03:18 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Bradner ,
        Sip list 
Subject: Re: Billing SIP proxy
References: <200003280340.WAA00664@newdev.harvard.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



Scott Bradner wrote:

> > The question is: is it posible to define, to any extent, a mechanism
> > capable of preventing the "hacked" terminal to bypass the proxy and call
> > the "standard" endpoints witout being billed ?
>
> if they are not making any special use of the network (like QoS
> reservations or fancy proxy services ) why should they be billed
> in a way that is different than any other best-effort use of the
> network?
>

Hi Scott,

Scott Bradner wrote:

> > The question is: is it posible to define, to any extent, a mechanism
> > capable of preventing the "hacked" terminal to bypass the proxy and call
> > the "standard" endpoints witout being billed ?
>
> if they are not making any special use of the network (like QoS
> reservations or fancy proxy services ) why should they be billed
> in a way that is different than any other best-effort use of the
> network?
>

Some telephony applications are currently heavily billed, at a rate much
higher than the corresponding rate for pure best effort Internet access.

In some domains, network operators hold a kind of oligopoly, thanks to
government policies, that grant licencies only to a very restricted number of
operators.
Please don' t quote me on this, but I would say that there is no real
competition between them, at least not harsh competition.

At the moment, they are deciding wheter to continue with circuit switched
networks or whethether to adopt IP-based networks.

It is very likely that they make such a step *only* if they don' t see their
revenues reduced (hopefully, they would like to increase them !)

A model where best effort calls are free and QOS calls are billed will pobably
apply in the future, but not in the short run, at least IMHO.

Giuseppe






From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 31 09:22:36 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13909
	for ; Fri, 31 Mar 2000 09:22:35 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 48B4752D5; Fri, 31 Mar 2000 09:05:41 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id CBDE352DC; Fri, 31 Mar 2000 09:05:39 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 3977E52F4
	for ; Tue, 28 Mar 2000 04:15:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 04:14:34 EST 2000
Received: from mail.iagu.net ([203.32.153.69]) by dusty; Tue Mar 28 04:14:33 EST 2000
Received: from dhcp-32-247.ietf.connect.com.au [169.208.32.247]
  by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id SAA03801
  return ;
  Tue, 28 Mar 2000 18:44:17 +0930 (CST)
Message-ID: <38E0E174.92E16C4@tin.it>
Date: Tue, 28 Mar 2000 18:44:36 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: David Oran , Sip list 
Subject: Re: Billing SIP proxy
References: 
Content-Type: multipart/alternative;
 boundary="------------5BD37DEA56C0FCBC6701A7D4"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


--------------5BD37DEA56C0FCBC6701A7D4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

David,

David Oran wrote:

> >The question is: is it posible to define, to any extent, a mechanism
> capable >of preventing the "hacked" terminal to bypass the proxy and call
> the >"standard" endpoints witout being billed ?
>
> There's no way to prevent one "hacked terminal" from talking to another
> "hacked terminal" directly, bypassing any proxy.
>

Fine, this is just impossible to prevent.

Then, I had in mind some via-header based solutions but, eventually, I managed
to hack all of them. It looks like the one you propose requires some more
thinking.....

> You can, at some pain, protect against is having a "standard terminal"
> answer a call from a "hacked terminal". The way you do this is when a SIP
> message comes into the UAC, ou look at the last VIA on the via list. You
> then get the IP address of that machine (either because it was on the VIA
> istelf or you called DNS to get its address) and compare that with the
> source address of the SIP message.

I assume you mean "Source address of the IP packet containing the SIP message",
right ?

> If they don't match, you know somebody is
> trying to spoof you.

mmm, let me think....

got it !?!?!?

   * 1) what if there' s a NAT in between ?

   * 2) vhat if the proxy "must be in the list", but not necessarily as  the
     last one ? (E.g. because the proxy that bills you is that of your "home
     network", and you have moved somewhere else)

   * 2) on the other hand, if you  want the billing proxy always to be the last
     one (apart from all the clearinghouse-related issues Henry was mentioning
     today), it must be communicated upon registration. I must think about this,
     but I have the feeling that a possibility might be that  I can fool the
     "standard" terminal to re-register with me (the hacked terminal) making him
     believe I am "the proxy". I would obviously be adding my address to the VIA
     header when inviting him.

   * 3) I will think a little bit more about it

   * 4) Anyway, do yo agree with me that the complexity of the "crack" required
     to "patch" such features on the "standard" terminal (going back therefore
     to the first case you mentioned) is definetly much smaller than that of
     installing a complete protocol from scratch on a device that was not
     designed to run it ?

Thank you very much and
Best Regards
Giuseppe

>
> If they DO match, then if the SIP UAC knows the list of SIP proxies which it
> trusts to deliver calls (and bill for them), the UAC either accepts or
> rejects the request appropriately.
>
> > Please CC replies to gricagni@tin.it (it is easier for me to read email
> from > such mailbox here in Adelaide)
>
> >Please let me know
> >Best Regards
> >Giuseppe

--------------5BD37DEA56C0FCBC6701A7D4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



David,

David Oran wrote:

>The question is: is it posible to define, to any
extent, a mechanism

capable >of preventing the "hacked" terminal to bypass the proxy and
call

the >"standard" endpoints witout being billed ?

There's no way to prevent one "hacked terminal" from talking to another

"hacked terminal" directly, bypassing any proxy.

 

Fine, this is just impossible to prevent.

Then, I had in mind some via-header based solutions but, eventually,
I managed to hack all of them. It looks like the one you propose requires
some more thinking.....

You can, at some pain, protect against is having
a "standard terminal"

answer a call from a "hacked terminal". The way you do this is when
a SIP

message comes into the UAC, ou look at the last VIA on the via list.
You

then get the IP address of that machine (either because it was on the
VIA

istelf or you called DNS to get its address) and compare that with
the

source address of the SIP message.

I assume you mean "Source address of the IP packet containing the SIP message",
right ?

If they don't match, you know somebody is

trying to spoof you.

mmm, let me think....

got it !?!?!?

    

  • 
1) what if there' s a NAT in between ?
    • 




    

  • 
2) vhat if the proxy "must be in the list", but not necessarily as 
the last one ? (E.g. because the proxy that bills you is that of your "home
network", and you have moved somewhere else)
    • 




    

  • 
2) on the other hand, if you  want the billing proxy always to be
the last one (apart from all the clearinghouse-related issues Henry was
mentioning today), it must be communicated upon registration. I must think
about this, but I have the feeling that a possibility might be that 
I can fool the "standard" terminal to re-register with me (the hacked terminal)
making him believe I am "the proxy". I would obviously be adding my address
to the VIA header when inviting him.
    • 




    

  • 
3) I will think a little bit more about it
    • 




    

  • 
4) Anyway, do yo agree with me that the complexity of the "crack" required
to "patch" such features on the "standard" terminal (going back therefore
to the first case you mentioned) is definetly much smaller than that of
installing a complete protocol from scratch on a device that was not designed
to run it ?
    • 





Thank you very much and

Best Regards

Giuseppe

 

If they DO match, then if the SIP UAC knows the list of SIP proxies
which it

trusts to deliver calls (and bill for them), the UAC either accepts
or

rejects the request appropriately.

> Please CC replies to gricagni@tin.it (it is easier for me to read
email

from > such mailbox here in Adelaide)

>Please let me know

>Best Regards

>Giuseppe



--------------5BD37DEA56C0FCBC6701A7D4--




From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 31 09:39:18 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14116
	for ; Fri, 31 Mar 2000 09:39:18 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 8955952E0; Fri, 31 Mar 2000 09:10:29 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id EC6C652DF; Fri, 31 Mar 2000 09:06:23 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 9411052F4
	for ; Tue, 28 Mar 2000 04:35:06 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 28 04:34:25 EST 2000
Received: from mail.iagu.net ([203.32.153.69]) by dusty; Tue Mar 28 04:34:24 EST 2000
Received: from dhcp-32-247.ietf.connect.com.au [169.208.32.247]
  by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id TAA03838
  return ;
  Tue, 28 Mar 2000 19:04:09 +0930 (CST)
Message-ID: <38E0E61B.621A1D81@tin.it>
Date: Tue, 28 Mar 2000 19:04:28 +0200
From: Giuseppe Ricagni 
X-Mailer: Mozilla 4.51 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" 
Cc: sip@lists.research.bell-labs.com, "gricagni@tin.it" 
Subject: Re: Billing SIP proxy
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit



"Fairlie-Cuninghame, Robert" wrote:

> I agree with Jay that this is not a SIP protocol issue but a network issue.
> If you want to prevent hacked terminals located on your own network from
> accessing the Internet then simply use a SIP Proxy-Firewall solution.

 what if both terminals are on my same network ? Where do I put the firewall ?

Cheers
Giuseppe

> Now
> UAC's cannot access the outside Internet unless they authenticate themselves
> to the proxy-firewall. Likewise, the proxy-firewall does not allow external
> clients to talk to internal terminals without authentication. The
> Authentication procedures are expressly designed to ensure that only valid
> users have access to the proxy, however, you can only ensure that hacked
> terminals do not _bypass_ the proxy by coupling the SIP proxy with a
> firewall.
>
> Cheers,
>
> Robert.




From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 31 09:43:31 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14152
	for ; Fri, 31 Mar 2000 09:43:30 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id B453052E4; Fri, 31 Mar 2000 09:10:39 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B282552E7; Fri, 31 Mar 2000 09:09:37 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id 4F11B52BB
	for ; Wed, 29 Mar 2000 08:37:08 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Mar 29 08:35:14 EST 2000
Received: from mail-green.research.att.com ([135.207.30.103]) by dusty; Wed Mar 29 08:35:12 EST 2000
Received: from postal.research.att.com (postal.research.att.com [135.207.23.30])
	by mail-green.research.att.com (Postfix) with ESMTP
	id 7CDD21E06E; Wed, 29 Mar 2000 08:35:10 -0500 (EST)
Received: from research.att.com (castle7027.research.att.com [135.207.231.27])
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id IAA18715;
	Wed, 29 Mar 2000 08:35:07 -0500 (EST)
Message-ID: <38E2065B.95DCA085@research.att.com>
Date: Wed, 29 Mar 2000 08:34:19 -0500
From: IPTS 2000 
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: iptel@lists.research.bell-labs.com, pint@lists.research.bell-labs.com,
        sigtran@standards.nortelnetworks.com, sip@lists.research.bell-labs.com
Cc: ipts2000@research.att.com
Subject: Initial CFP: IP Telecom Services 2000 Workshop
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit

[Please accept our apologies for multiple copies of this call.]

-------------  PRELIMINARY CALL FOR PAPERS  ---------------

       IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000)

                    co-located with
             Fall 2000 Voice on the Net (VON)

                     organized by
                  AT&T Labs Research
                      pulver.com

         Cobb Galleria, Atlanta, Georgia, U.S.A
                  September 11, 2000

            submission deadline: June 16, 2000
         http://www.research.att.com/conf/ipts2000/

-----------------------------------------------------------

IPTS 2000 is a new workshop dedicated to the important, emerging field
of IP Telecom Services research.

In contrast to the services available on the PSTN, a new world of
telecom services is possible on an IP-based infrastructure. This world
presents new challenges for service development, deployment and
management. This one-day workshop will serve as a forum for the
dissemination of research relating to these challenges.

The IPTS 2000 Program Committee invites submission of papers on
substantial, original and previously unpublished research in IP
telecom services, including, but not limited to:

- service architectures
  (e.g. AIN, SoftSwitch, JAIN, Parlay, DFC)
- service creation environments
- protocols, standards and interoperability
  (e.g. H.323, SIP, MGCP, Megaco/H.248, etc.)
- service programming languages
- service management - billing, fault tolerance, monitoring
- novel services

We welcome papers describing original research; position papers
describing research interests in the field, work in progress, or
future directions of research; project or system descriptions.


IMPORTANT DATES

June 16, 2000        Submission deadline
July 21, 2000        Notification of acceptance
August 25, 2000      Final version of papers
September 11, 2000   IPTS 2000


PAPER SUBMISSIONS

Papers must describe original, previously unpublished work that has
not been simultaneously submitted for publication elsewhere. They must
be written in English, not exceeding 6 pages including figures, tables
and references in 10-12 point font on 8.5x11-inch (US letter) paper.
The first page must include an abstract of up to 200 words, keywords,
and email address of the corresponding author.

All papers must be submitted electronically unless specifically
approved by the Workshop Co-Chairs. Submissions in PostScript or PDF
format should be sent to mailto:ipts2000@research.att.com.

Authors of accepted papers are expected to present their contribution
at the workshop.  The proceedings will be published in hardcopy and on
the web.


REVIEW PROCEDURE

All submissions will be subject to academic peer review by the IPTS
2000 Program Committee under the chairmanship of the Workshop
Co-Chairs. Each paper will receive three written reviews, and reviews
will be returned to the authors.  The Workshop Co-Chairs have final
authority over the review process and all decisions relating to
acceptance of papers. Review criteria include originality of ideas,
technical soundness, significance of results, and quality of
presentation.


CONFERENCE VENUE AND RELATED EVENTS

IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The
workshop will be co-located with Fall 2000 Voice on the Net (VON). 
Details about Fall 2000 VON can be found at http://pulver.com.

IPTS 2000 is organized by AT&T Labs Research
(http://www.research.att.com) and pulver.com (http://pulver.com).


WORKSHOP CO-CHAIRS

Greg Bond, AT&T Labs Research
Eric Cheung, AT&T Labs Research

PROGRAM COMMITTEE

Mauricio Arango, Sun Microsystems Labs
Joanne Atlee, University of Waterloo
Ralph Blumenthal, Daewoo Telecom
Scott Hoffpauir, BroadSoft
Evan Magill, University of Strathclyde
Peter Mataga, dynamicsoft
Bernie Pagurek, Carleton University
Jonathan Rosenberg, dynamicsoft
Henning Schulzrinne, Columbia University
Greg Utas, Nortel Networks
Pamela Zave, AT&T Labs Research


FURTHER GENERAL INFORMATION

http://www.research.att.com/conf/ipts2000



From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 31 09:51:13 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14215
	for ; Fri, 31 Mar 2000 09:51:13 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id E136252EA; Fri, 31 Mar 2000 09:13:23 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id CBB8652DD; Fri, 31 Mar 2000 09:10:30 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id C7C5352C4
	for ; Thu, 30 Mar 2000 21:39:05 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Mar 30 21:37:35 EST 2000
Received: from westhost16.westhost.net ([216.71.84.74]) by dusty; Thu Mar 30 21:37:35 EST 2000
Received: from ipunity.com (w226.z208176132.sjc-ca.dsl.cnc.net [208.176.132.226])
	by westhost16.westhost.net (8.8.5/8.8.5) with ESMTP id UAA01781
	for ; Thu, 30 Mar 2000 20:24:32 -0600
Message-ID: <38E40F9F.3AC5F14F@ipunity.com>
Date: Thu, 30 Mar 2000 18:38:23 -0800
From: jimmy Zhang 
X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.research.bell-labs.com
Subject: help on SIP headers
Content-Type: multipart/alternative;
 boundary="------------CF04A0D5C12302700379CA8E"
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk


--------------CF04A0D5C12302700379CA8E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Since I am pretty new to SIP, please forgive me for asking naive
questions, such as
the following one.

   In the specificiation, both "to" and "from" fields require the sip
address to be in
the form of either "sip:agb@bell-telephone.com" or "anonymous
".
But I just collected some sample messages in which both "to" and "from"
headers were
in different looks, e.g. "to: isbn:2983792873" and "From:
http://www.cs.columbia.edu". Just
wondering if anyone could explain, in the case that they are both
valid,  why http URL would
be allowed in the From or To headers? Also, aside from "isbn", what are
other possible
prefixes allowed?

thanks,

--

Jimmy zhang (jz@ipunity.com)

Software Engineer



--------------CF04A0D5C12302700379CA8E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Since I am pretty new to SIP, please forgive me for asking naive questions,
such as

the following one.

   In the specificiation, both "to" and "from" fields require
the sip address to be in

the form of either "sip:agb@bell-telephone.com" or "anonymous <sip:c80fsfsl@privacy.org>".

But I just collected some sample messages in which both "to" and "from"
headers were

in different looks, e.g. "to: isbn:2983792873" and "From: http://www.cs.columbia.edu".
Just

wondering if anyone could explain, in the case that they are both valid, 
why http URL would

be allowed in the From or To headers? Also, aside from "isbn", what
are other possible

prefixes allowed?

thanks,

-- 


Jimmy zhang (jz@ipunity.com)

Software Engineer

 

--------------CF04A0D5C12302700379CA8E--




From owner-sip-outgoing@lists.research.bell-labs.com  Fri Mar 31 09:53:41 2000
Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14227
	for ; Fri, 31 Mar 2000 09:53:41 -0500 (EST)
Received: by lists.research.bell-labs.com (Postfix)
	id 494C252BB; Fri, 31 Mar 2000 09:37:39 -0500 (EST)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006)
	id B47995312; Fri, 31 Mar 2000 09:37:38 -0500 (EST)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10])
	by lists.research.bell-labs.com (Postfix) with SMTP id C194852BB
	for ; Fri, 31 Mar 2000 09:37:07 -0500 (EST)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Mar 31 09:35:51 EST 2000
Received: from c9.egroups.com ([207.138.41.187]) by dusty; Fri Mar 31 09:35:50 EST 2000
X-eGroups-Return: dmalhotra@hss.hns.com
Received: from [10.1.2.123] by c9.egroups.com with NNFMP; 31 Mar 2000 14:35:49 -0000
Date: Fri, 31 Mar 2000 06:35:44 -0800
From: "Dhiraj Malhotra" 
To: sip@lists.research.bell-labs.com
Subject: join
Message-ID: <8c2d40$3nb2@eGroups.com>
User-Agent: eGroups-EW/0.82
X-Mailer: eGroups Message Poster
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk